Absolutely this. Developers focus too much on the technical issues they can see, and not the business and regulatory ones that they aren't exposed to. We as developers have to start thinking about the boundaries between companies serving as legal/regulatory entities rather than strictly technical ones.

To use a non tech example: If Uber wants to offer drivers cars to rent to use for Uber, naively you might assume they'd buy cars and then rent them to drivers. But no, they partner with a company that just rents cars, and have that company offer the cars for rent, facilitated by Uber. There's no technical barrier to Uber buying the cars and renting them out themselves. But they do not want the liability associated with upkeeping the car, and they want the ability to fire and replace the rental car company in the future. There are also accounting benefits to keeping assets like rental cars off of your company's books.

In software it's very similar. Could most companies build a simple enough set of software to run their business? Absolutely, especially these days with vibe-coding. But externalizing that responsibility allows you to switch software vendors, or sue your vendor if something goes wrong rather than take responsibility yourself. (You can play this out mentally with consumer lawsuits as well.)

In this lens it's easy to see why "slop" is tolerated: software working as designed is not necessarily the primary concern of the buyer or seller. To go back to the rental car analogy: Neither Uber nor the rental car company really cares if the cars are ugly or broken, as long as they can do the bare minimum, and the users suffer.

To make quality a central concern you either have to regulate it directly (as we do with banking/healthcare software) or you have to have a legal regime that disallows the externalization of risk.