- More bugs
- More vulnerabilities
- Increasing cost of support
Which absolutely impact the customer experience, just not in the short-term. A little bit of short-term friction averts long-term intractability.
To put this in another context: newer building codes may result in better and safer homes, but it'd be extremely user hostile to force homeowners proactively upgrade their homes to compliance each time a new version is released (at the threat of having their home condemned if they do not). The sensible compromise, in buildings and software, is to allow things to be upgraded over time, as they're modified.
They affect it far worse, because they affect _every_ user. Having unmaintained/outdated software break only affects the subset of users that want to use that particular software.
One huge market where this does happen is games. Disregarding the current plague of microtransaction-funded 'live experiences', most games are pieces of software that get released and are mostly done, barring some added content going out for a year or two. Losing the ability to play these games because someone has decided that ABI compatibility is kinda hard is ridiculous, and would definitely not fly for a consumer OS.
It would be interesting for someone to try to apply this same argument to hardware: would it make sense to abandon old hardware support every release? Doing this with device drivers was one of the things which hurt Linux adoption on the desktop, and hurt Windows Vista's release immensely.
Overall, end-users do not and should not care for OS updates. They are a necessary evil, to help fix bugs that the OS developers missed that threaten their security; and to be able to use new applications that rely on new OS features. But breaking old applications or hardware is a massive pain point that makes users weary of updating despite the risk to their security.
Old games have a tendancy to break reasons even without ABI breaks..
I think it's ridiculous that games are still primarily closed source binary blobs that cannot be easily fixed and patched by the users to keep them running fine for decades.
Breaking backwards compatibility has a larger negative impact in the _present_ than the cruft of old APIs and code. But that impact is temporary. However, the negative impacts of cruft can have a larger impact _in total_ over the entire lifetime of the operating system.
It's not a bit of short-term friction, it's constant friction. As long as development is continuing, there's always something about the API that can be improved and would really pay off if only that was actually its final state and not just the next step until we find a good reason to break it again.
I think the implicit calculation here is that if you push a release that breaks the user's workflow, they can point to a specific point in time where things became frustrating and there will be a PR hit at that moment in time.
If instead you maintain compatibility, the small costs of all the technical debt accrue over time to make the experience worse than it might otherwise be, but users may not even notice or have a conception of what they may be missing for having stayed on this path.
They ultimately may end up with a worse product / UX, but they have no specific reason to complain about it.