I agree, but to me that's why it's dangerous to think about refactoring the whole codebase at once, whether strangler or rewrite. Project design is just like so

I agree, but to me that's why it's dangerous to think about refactoring the whole codebase at once, whether strangler or rewrite. Project design is just like software design, you need to be design it for failure scenarios, eg business priorities shifting, poor execution, etc, without leaving the overall situation in a worse state than when you found it. If you design a long lived code cleanup project where the only option is "we can't stop this project for another 6 months or we'll have an even bigger mess on our hands," that's poor project design. In this way, rewrites are almost safer. They're usually "atomic" and you can "roll back" by throwing it out if you can't focus on them. All this is based on dynamic business and product needs that are shifting every couple of quarters, and a technical team that's getting new people, and shifting off more experienced folks every couple years. That seems to be a pretty standard expectation to me, though I'll admit I'm mostly looking at this through the lens of early, mid, and late stage startups. It may be big companies that move slowly and can guarantee resources for a larger project for a long time are a different story.