>Performance isn’t a luxury—it’s foundational.

Reasons to always try to be nearly optimal on performance from the start, that I rarely saw stated:

1) What you can specify depends on what can be done, and to know what can be done you need to have tried your best. In particular, it allows to see early whether or not performance expectations are reallistic.

2) It's more difficult or impossible to upgrade performance later if it requires to break an API. It causes a development process in O(n^2) in number of layers, instead of O(n).

3) Better lower level performance makes higher level code and architecture simpler, as you can just brute force in more places for a same overall performance.

No offence intended, however, this is literally the pitch I have seen for why startups with 5 users need to architect their product to be global scale for 1 billion concurrent users. (those that try always burn out and fail)