This very much is a solved problem - it comes down to standardization in tools, categorization of incidents, keyword analysis of incident description, and (probably automatable) correlation with logfiles and identifiers. Preventive maintenance is not a concept that has been around only recently, and a good QA team has a whole toolkit of things to throw at code before it hits the customer. And yes, ultimately, it is a question on whether you invest the resources to deal with the dumpster fire, or just let it burn to ashes. I am also a big believer in "You build it, you run it", and a "no new features as long as there are open bug tickets" approaches, making teams responsible for their own technical debt.

Google with it's "Let's never maintain our products, let the bitrot make them gradually worse and eventually EOL them" approach seems to prefer to avoid that kind of cost.

I used to be a Google fanboy in the early 2000s. Maybe it's coming with age, but these days I prefer boring tech that works well as compared than half-baked moonshots, and Google may have burned me once too many. Other software megacorps (and even some NGOs) do this better than the big G.