In addition to Second System Syndrome that has already been covered, I think there are several other things going on here that lead to the tug of war.

In another reply I already mentioned a flavor of Sunk Cost, which is resistance to any change to the code that 'made us successful' because they consider they have already won and taking it away now is some sort of revisionist history effort instead of just Progress. Hofstadter's Law, which tells you we still have plenty of time, despite three initiatives already having finished long past the point of maximum tolerable pain already.

But more damningly, I have worked with a lot of people who want to skip from Make it Work straight to Make it Fast without Making it Right in the middle. Those are the people who, among other things, reach for caching too early, and then declare the war for cost reductions over before they've even started, because there are no perf analysis tools that can see past and around the caching logic to find the issues that caching either didn't fix or made much much worse.

I'm not advocating for making hot decisions at every point along the way. I'm advocating for people having enough experience and foresight to understand which 20% of the code flow is Architecture from which is just feature factory work and making sure that 20% gets 80% of the design thinking and timely preventative maintenance.

On a couple projects I've just done all that myself. But it is a quick road to being a bottleneck and then to burnout. You have to aggressively recruit people to be bus numbers on all of those things. This is part of why I do so much mentoring.