Or, are you responsible for delivering any services, and if so, do you not mind when someone else's changes cause you an outage?
Perhaps you have some private automation in place; do you not mind if your automation breaks because of someone else?
Apropos bloat, illumos is the only operating system codebase which gets faster and more efficient with every commit. If there are others out there, I have yet to see such a thing.
I'm happy enough if people say "okay, we didn't get this quite right, but we learned and we've made it better". And if the new approach isn't compatible, well okay. The short-term pain is usually worth moving forward in the long-term.
And when this happens, it's usually not a technical issue anymore, but a communication issue, which is a way harder problem to solve. If your solution to the communication problem is technical, i.e. let's always maintain backwards compatibility, then there's still the issue of communicating what the new, preferred method is. So I feel that if you have great communication with the people who care, it shouldn't impact them badly in the first place.
The danger of backwards compatibility is maintenance cost, and stifling new ideas to solve an existing problem better - people won't bother, because the effort of making something new would be overshadowed by the effort to retro-fit old behaviour.
Still though, I get the point of changing stuff just for the sake of change is bad. I'll ignore the hyperbole about illumos though.