Premature optimization is extremely subjective. You can’t actually make any decisions based on it because the data you need to know if it’s premature is in the future.
Conversely we know you can’t make an unscalable design scalable after the fact. You may be able to do micro optimizations of hotspots or fix the egregiously bad parts but you’ve painted yourself into a corner.
The good news is that most scalable architectures are simpler and better in most other facets of the design so it’s largely a false dichotomy.
Yep; the quote was originally about in line optimizations, like profiling to avoid cache misses and tightening inner loops and such. Nowadays, with your main concern being service throughput, the bigger concern is your architecture, not your implementation.
Which is where the confusion is, possibly. Architectures you can't easily undo; that loop or choice of data structure you can. So it's generally worth giving careful consideration towards your architecture (it's not premature to ask "What happens when this one thing becomes two?")); it's generally not worth giving the thought towards your implementation.
Conversely we know you can’t make an unscalable design scalable after the fact. You may be able to do micro optimizations of hotspots or fix the egregiously bad parts but you’ve painted yourself into a corner.
The good news is that most scalable architectures are simpler and better in most other facets of the design so it’s largely a false dichotomy.