[Bartweiss]

Truly gnarled legacy code can be almost impossible to understand just by reading, so that truly grokking it requires writing something in the codebase. (Mind, that's necessary for understanding but not sufficient.) And so at a certain point the question becomes - if you can spare the time to go beyond one-off hacks, why isn't that dev time going into adding test coverage, simplifying, etc?

There are still times when knowledgeable legacy maintenance is the right answer, I think. In particular, the Catch-22 of systems built without the capacity for online updates which can't be taken down to add that capacity. I've heard horror stories of the deeply-understood hacks that keep telephone networks running, because they're ancient monoliths contracted to >99.9% uptime. But in general, the argument for not rewriting legacy code is that it takes too long, or it's going to be expired eventually, and so relying on the original author or hacking in changes is more efficient. It seems like "don't rewrite it, but repeatedly spend the time to bring new people up to full expertise" has a very narrow window where it's the right choice.