"Bad practices" often don't start out as bad practices; circumstances change. Additionally, some "bad" things are more like "dangerous if improperly handled" things (e.g. Rules), so making them impossible cripples users.

Lastly, there exist some useful, maintained libraries/tools with a substantial proportion (or majority) of "client" codebases at or greater than 20 years of age. Just because something has been around for a long time is not an excuse to break it. Just because something has not been maintained does not mean it is necessarily poor engineering or deserves to suffer for the passage of time.

And you should always be able to upgrade the software you have without fear of breakage, because maintaining a fork and/or deciding which versions to use is often untenable as it relies on specialized knowledge which may not exist in your organization. If you as a software dev want to maintain a clean code base with no deprecated features, you are free to build one. That's not what this is, and you shouldn't expect anyone else to use it if it were.

It's not 'common sense' or 'sanity' to break existing code bases. Companies and individuals have generally spend millions on their software and breaking changes cost time and money. There's a reason that Python 3, for example, took over a decade to be fully adopted. Breaking changes should only be implemented with considerable evaluation of the actual need and of existing options. If users cannot rely on you to not break their systems, they will move on to someone they can rely on.

"either don't upgrade or fork away, don't make others suffer for your unwillingness to change."

I manage a number of databases, mostly of a financial nature, and I can tell you that if I were using a database system developed the way you suggest I'd be in trouble. On the one hand, I have to keep my data secure so I have to patch my systems on a regular basis so I can't use a version of a database system that isn't being actively updated. On the other hand, I have to manage hundreds of thousands of lines of mission critical code, most of which I didn't write, and a large amount of data which absolutely, under no circumstances, can be lost, if I want to keep my job. To that end, I can risk breaking changes and usually wouldn't have the bandwidth to accommodate them if I could. There's a reason that many big companies are still using mainframes despite their being better options: rule number one as a system administrator is to not break the existing system.

"a better example commenters could focus on is the type `money` - if best advice from postgres about handling money is to not use `money` type - it shouldn't be part of postgres. how is that in any way controversial?"

Let's actually take this example seriously. Let's say that there is an off-the-shelf accounting system that uses PostgreSQL and because of bad decisions made in the past, uses the 'money' datatype internally. Presumably they've worked around its limitations so it's no longer an issue for them. Let's say that PostgreSQL decides to remove this datatype in the next release of the database. Well, suddenly not only does that accounting system no longer work, bu every company that uses the software is SOL. In addition, any integrations and custom code that worked with that accounting system are now broken. This is a loss of millions of dollars in software dev time at the very least. There's also a possibility of dataloss, which when talking about accounting systems is a matter of legal compliance. This is a much worse outcome than people accidentally using 'money' in new development in future. Considering that the later problem can be ameliorated with just a warning, that seems like the more obvious trade-off.