Yes, without government coercion, it's simply Thier's law: good money drives out bad. So if software tends to degrade over time, what's playing the perverse role of preventing people from switching to better modules/software?
There are of course all sorts of ways that a public API can become an entrenched standard (x86, Windows, PHP, JavaScript, C++, HTML, Java). Collectively we call it "lock in".
The thing is, the software wouldn't have been adopted in the first place if it didn't fulfill some need. Evolutionarily speaking, it's better for the cost of removing to be high and the benefit of keeping it to also be high. The most evolutionarily fit would be software that's essential, yet complicated, obscure, and unsexy, so it doesn't attract attention of idealists who will put in sufficient resources into rewriting it.
Even better if it attracts passionate advocates who will fight removal.
OpenSSL immediately comes to mind, but I don't think JavaScript really fits the model - it is still evolving into a better language. In a very real sense, EMCA7 is an entirely different language than EMCA5.
Managers? They don't stop bad code that still solves the problem but they do stop refactoring and other improvements that aren't directly tied to a customer's issue.
...or the customers themselves, who are unwilling to pay for any change for which they cannot gauge the impact upon their user experience. Sometimes the management explicitly says, "We know this is bad practice, but the customer will not pay for good."
This is why cheats like the "speed up loop" appear. If developers can justify any change to the code on the basis of perceived performance improvements, there is an incentive to intentionally degrade initial performance in an easily reversible way. Removing the speed bump is then bundled with the developer-desired refactoring.
The practice is ethically dubious, but then again, so is allowing an ignorant to command an expert in his own area of expertise. When the management has no understanding of technical debt or the software life cycle, some may choose to simply pre-pay some of the pension plan for the product's maintenance phase out of the development budget, rather than waste time explaining things.
The management life cycle plans for some software products are very much like a prospective father, who decides that his child will be born in 4.5 months, because he'll assign two mothers to the gestation project, instead of just one. It will learn calculus by age 4, will be fully grown by age 8, and will be more beautiful than an airbrushed model. It will then stay young and productive forever, while working 24-7, without complaint, for the benefit of the family. When the kid dies from everything cancer at 12, the dad blames the doctors, who did exactly as he asked, while repeatedly warning him that deviating so widely from the established parameters for life is certain to end in disaster.
You cannot command a doctor to raise the dead. You cannot command a lawyer to win the case. You cannot command the contractor to build the structure as both "safe from EF5 tornadoes" and "with lots of windows". You cannot order the scientist to find significance in the experimental data. And you can't tell a software team to build the "do what I want button" in a short amount of time, with a tiny amount of money, with great quality.
The basis behind Gresham's Law is that the state fixes one variable for market value and intrinsic value is left floating. People retain the items with the highest ratio of intrinsic value to market value (good money), and spend those with the lowest (bad money). Everyone does it, so the worst money circulates fastest.
In the case of software, the quality is often fixed at "meets customer requirements" and the cost is left to float. People with the lowest cost to quality ratio are retained, and those with the highest are let go. If the cost variable were fixed instead, higher-quality software would dominate.
