Earlier quoted context omitted.
Not getting rid of "legacy" stuff that doesn't work is a, IMHO, a version of throwing good moneybafter bad money. Instead of acknowledging that the unusable code, or whatever, was a crucial part of understanding the problem, and throw it out once the problem was understood, people tend to build upon those not fit for purpose things...
Some of the most valuable work I've ever done was spending a month creating something, throwing every byte away, and then spending two weeks creating the same thing, much improved. The key to rework like this is you have to actually be able to finish it and get rid of the old, instead of spending months or years maintaining two half-baked versions of something instead of just one.
The finished projects tend to stick around forever and, if they need maintenance, it’s adding a feature or two or updating dependencies.
I do backend work so this kind of workflow probably doesn’t work for customer-facing projects that need to iterate on finding traction. But for something where the problem is generally well defined and not likely to change drastically in the short or medium term, it’s amazing. I have multiple projects I’ve written that run on virtually every machine (server and workstation) at my company (former unicorn, current Fortune 500) that are effectively “done” and only need to be redeployed a couple times a year for dependency updates and preventing bitrot in general.
Having worked like this, I can confidently say I will never again remain on a team where this isn’t the normal state of affairs.