Premature optimisation of CODE is bad, but optimisation of code is only a small part of achieving good performance. Ideally:
0. At the start: Ensure the scope of the design fits with the reality of the hardware.
1. Very early on: Ensure the architecture of the engine + game will give the expected level of performance. Comes from understanding of the hardware and experience.
2. Early on: Set some rough budgets. "We're aiming for 60Hz so that's 16ms of GPU time to play with, world rendering must happen in around 8ms, post process in 2ms, etc". Same for CPU and memory. Have in-engine profiling for each system that shows how well each system is doing.
3. Throughout: Design and implement systems with performance in mind ("Cool, so algorithmically this O(blah) but what effect is that having on the cache?")
4. Throughout: Profile systems and check how close they are to the budgets you set. Adjust budgets if necessary. Analyse any systems that are wildly over to see why.
5. Later (alpha-ish onward): Profile systems against the budgets. Analyse all that are over. Optimise the ones that are over or borrow budget from a different system if you can't optimise any further.
Mindset is hugely important. Performance is a whole team thing not just a programmer thing, that's important to get across to everyone - have budgets for design ("you can have N cars on screen"), art ("main character models must fit within X MB, use no more than Y textures and have no more than Z bones"), audio ("must fit within N MB and use no more than M DSP effects at any one time"), etc.
[That's from my experience of shipping console, PC and handheld games, including a few that ran at 60Hz]