I used to work on a system that moved a hundred billion dollars a day. Yes, billion. Downtime costed thousands of dollars a minute simply in floating interest from money not moving, and a serious outage could damage the entire economy. That's some serious high availability requirements.

For purposes of its extreme performance and availability requirements, it barely worked. That doesn't mean it was bad code! It was great code. But it could have been better. It could have been much better. And it wasn't, because once it met those requirements, work got applied to expanding its feature set instead. Which was, in a way, also a requirement.

Pick any "impeccable level of quality" system, and you'll find the same thing. Heart monitors. Mars launches. Whatever. The software barely works, given the difficulty of the requirements. I'd argue that it's actually irresponsible for businesses to try to do any better than that! The cost of bouncing the rubble with code quality is a resource that could be much better spent on other things.

Think of it in terms of the 80/20 rule. Dig into that last 20%, and you'll spend 80% of your effort on it. It's not a good tradeoff. The Pareto Principle isn't a measure of how bad we are, it's a measure of how good we are. When we attend to its wisdom, we get the most work done.

edit: Scope is not the only requirement. Schedule is also a requirement! Pareto Principle again! Taking four times as long to get 20% better code is failure. We don't just have to create features. We create features with the resources we have, the technology we have, the people we have, within the schedule we have. A blown schedule is a failed requirement. Software not delivered on time is, in fact, broken.