It seems like most consumer apps incur a crazy amount of technical debt while largely paying people in equity, then if they take off raise a bunch of money to pay other people in cash to sort it all out... Pretty good system actually.
Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality. We may build some scaffolding and do some refactoring to prevent dropping into doesn't-work-land, but that's not the same as robust! So software - all software - hovers around that barely-works/doesn't-work borderline.
If you care about the outcome of a craft, you'll get craftsmen, and they'll produce things and you'll pick the best ones.
Imagine if a chef had to serve the first try at a new dish, if a photographer had to use his first shot, if a director had to use the first take, if a visual designer had to use the first concept. These processes are easier for people to understand because a layman can tell if two flavors didn't combine well, if a model blinked, or if something looks off. People (even technical ones) can't experience technical problems immediately or directly in the same way. Other fields solve for this with engineering, but ours rarely is allowed.
We often ship the first architecture that gets brainstormed, and the first implementation that works. It's never "We implemented the MVP using patterns/frameworks A, B, C, D, here's a table of the strengths and weaknesses as we see them, statistical summary of the time to complete each feature, and of defect rates. This next slide is a plot of the relationship between request latency, capacity, and estimated infrastructure cost of each implementation". It's rare to even have refactors scheduled. Just cleaning up your shit is "wasting time", never mind how long it takes to ship new features given how cluttered things are.
Sure, engineering is costly, so is not engineering - you just aren't projecting or measuring the latter costs. It's all trade-offs, if you aren't considering expected values of different options, with numbers, then you haven't optimized, you just rolled some dice. Sure, of course it's always worked, everything always have worked for the survivors. There's a big difference between what's unforeseeable and what has merely been left unforeseen.
Time to market and allocation of resources are serious issues for management. They may not understand the tech, but I've found engineers rarely understand the business context, either. "Good enough" is good enough. And we've seen process get more and more focused on this since the late '90s... Agile, Lean, etc. Get a product out the door, even if it's buggy and flawed. Get feedback from actual customers. Find out what's really a problem and what we only think will be a problem.
The fact is: software is a lemon market and teams/companies are rewarded accordingly.
Engineering isn't the latter end of that, it's precisely just the process of figuring out the trade-offs, the diligence of figuring out where on that spectrum (highly-dimensional continuum really) of process your project should be to get the greatest chances of success. Of course it includes time to market and concepts of "good enough". But it's math and planning and risk accounting and not the cargo culting, handwaving, business platitudes, salesmanship and politics of authority that get utilized in the majority of cases I've seen for making those decisions. These result in monuments to compromise -- the output of arguments between "captain cowboy" and "doctor diligent" (neither of which correctly account for real-world incidence of risk or what that costs the organization which employs them), arguments of engineering without any engineering being done.
Engineering isn't disconnected navel-gazing perfectionism, it's how you prevent it. Engineering is both why we don't live in Kowloon Walled cities, and why most places have water and plumbing and transportation despite a wide variety of obstacles and economic realities that would preclude "ideal" solutions.
This is the biggest issue, software is seen as something that is built, not something that has to be maintained, improved and extended.
It's amazing how companies can pour tens of millions into the build step and lose that investment by not maintaining and improving it.
Another one of those real-world insights I've had is a variant of Conway's Law... the software built by a team reflects that team's communication structures, but if you dissolve the team and hand maintenance to someone else, they'll never make sense of the original code, because it doesn't match the communication structure of the new team.
Then when they need to update it (say for a new version of IE) they can't find anyone competent to work on it because no one competent wants to work on such an outdated POS. A simple bug fix or added may involve upgrading a tonne of dependencies and code changes in the project is effectively dead.
By that point if it's worth sorting out it's already paid for the people to clean it up.