Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.
At least according to my experience and everyone I know in the industry.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.
It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.
The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one company I worked for, the policy was not 100% strict DRY. Instead, we waited for 3 uses of the same idiom before we put it in the library. This prevented the collection of too many trivial methods, while still giving the benefits of DRY.
What if there's no automated testing worth a damn, and the penalty for a bug is very high? Been there, done that, and I have to say, you don't ever want to stay there!
You don't see good looking legacy, because it didn't survive.
Technical debt manifests in a code base, most generally as various forms of pain that occur when trying to add features. That's how the company "pays interest" on the technical debt. Coding so that you can always change your mind, however that is accomplished, is the key there. (This is one place where the "Law of Demeter" really shines!)