Y'know, I can't help but think something's socially different between the time of "I have no users, so I'll do what I like" and "I have thousands of users, and need to make a change."
When it's a one-person project with no users, you can Move Fast and Break Things. But when you get users, that dynamic changes. Suddenly, it's not just about you, the developer. Now you have to put some thought into breaking changes. If you're lucky, you were smart and established that pre-1.0 is unstable, and your users will probably work with you and be more understanding of breakage until 1.0 comes out. That gives you and your users time to experiment and expand (or refine) the software. By 1.0, they're going to expect you to not treat them like an asshole, and they want some sort of warning before APIs become deprecated, so they have time to migrate their tools. They expect a project that is run well and actively communicates with users, addressing their concerns and (optionally) recommending other projects if the dev's project isn't cut out for the problem.
If you have a bunch of users and still act like there's just this one guy, there's a problem. Your users will eventually get sick of that toxic attitude, or feed into it and magnify its intensity. Either way, you're squandering your userbase and your software will suffer.
If you want case studies, take one look at Arch Linux or suckless. Both have some great resources on their side, but their community management is pathetic and dismissive. Neither of those communities see that as a problem since both of them revel in making their work harder to use, but other projects may see that as a severe blow to their potential.
Project management is just as much social as it is technical. Failing in either will limit a project.