They are saying if you are saying "this piece needs to be more performant" you need to measure that first, before making your choice of what to make better.
You are saying, "you can with an idea in mind optimize before you go and it will have better performance" but the current prevailing business logic is do not optimize until you know it's "the right thing".
AKA premature optimization is bad.
Did I mis-interpret what you are saying?
As such there are very few black and white rules you can follow and succeed.
The correct approach is somewhere to the left of "premature optimization" and somewhere to the right of "don't even think about performance until you can measure it".
More experienced and talented people will be more successful at picking that sweet spot.
Telling a dev that the correct approach is to pay absolutely no attention to performance before it can be measured is ... crazy IMO. I would expect them to have at least thought about it, and have some opinions, just as they should not have put excessive effort into prematurely optimizing things they don't know are going to be a problem.
My point is - its grey, use your brains, don't buy into absolute rules.
A lot of assumptions there and real world is almost never that clear-cut.
The general advice of "don't optimize until you've measured" is still almost always correct.
The issue of course being that when designing code, various design choices can have significant performance implications, and can be very hard to change once implemented and in production.