On the contrary, there's software written all the time that has a realistic lifetime of a few years before it's either replaced with a 3rd party alternative or rewritten by some disgruntled programmer. Deadlines and business priorities often mean that foregoing what most of us would tout as "best practices" actually makes sense. Some software is only used by 10 people at a time, and can be maintained by one or two engineers. It probably makes more sense for the engineers to choose what's best for them and the company over what most people would say are the right things to do. There are people I know who don't write tests for their software(something I don't know that I would ever do), but each piece of software they write is small and has a lifespan of a few years at most, and the advantage to removing barriers to development is that they can make changes very quickly and get things done.
If anything, FAANGs have resources and intertia to actually work on technical debt. Smaller companies will just churn and churn and churn until they bog down into unmaintainable mess of a code and can't respond to market changes anymore because their codebase is impossible to change or maintain.
Then they'll usually call us to fix their issue and be angry when the answer is "there's no easy way out of the mess you caused" while their competition is moving ahead of them.