I don't see Pike recommending one ignore performance and I assume given the target audience for the advice, the audience is assumed to know that you can't ignor

I don't see Pike recommending one ignore performance and I assume given the target audience for the advice, the audience is assumed to know that you can't ignore performance in the same way that a chef knows you can't ignore presentation. The focus of the advice to me is that software engineers frequently overestimate their ability to predict performance bottlenecks and efficiently allocate time to preemptively address them in the middle of writing the core of the system (for multiple reasons, including both the overall complexity of a complete system and the fact that performance is also a function of the way users interact with the system). I've built multiple systems where a component we never expected to become a bottleneck becomes the bottleneck because users choose to use the machine in an extremely novel way relative to our intent when we built it. Getting the software in front of users to get signal on the difficult-to-predict user factor was consistently a better use of our time than swapping out a functional n squared algorithm with an also functional n log n algorithm on a piece of the system that no users were operating with yet.