I would argue that these:

- 'commitment to zero technical debt'

- 'design for performance early'

Will save you time and cost in designing, even in the relatively near term of a few months when you have to add new features etc.

There's obviously extremes of "get something out the door fast and broken then maybe neaten it up later" vs "refactor the entire codebase any time you think soemthing could be better", but I've seen more projects hit a wall due to leaning to far to the first than the second.

Either way, I definitely wouldn't call it "privileged" as if it isn't a practical engineering choice. That seems to judt frame things in a way where you're already assuming early design and commitment to refactoring is a bad idea.