Il existe plein de versions de cette "règle", j'utilise souvent do not optimize early mais c'est lié au contexte où je l'utilise, à savoir dire à un junior de ne pas vouloir optimiser tout de suite ce qu'il fait.
Faire de l'optimisation prématurée, c'est au final vouloir régler un problème qui n'existe pas, du moins pas encore. Quand on implémente quelque chose, la première étape c'est de faire en sorte que ça fonctionne. Ensuite il faut respecter le clean code et avoir un code lisible. Enfin seulement on pourra éventuellement regarder si les performances méritent qu'on s'y penche ou pas.
Alors évidemment je ne dis pas qu'il faut produire du code non-performant ! Ce que je dis c'est qu'il ne faut pas y consacrer trop d'efforts ni de temps.
Il ne faut pas volontairement faire du code stupide dans le but qu'il soit lent... Je fais du code lisible qui fonctionne et ensuite je regarde si les performances sont correctes. Si elles sont mauvaises alors oui on va y passer du temps. Le faire à la fin c'est s'assurer que ses optimisations ne seront pas inutiles.
Exceptions
Évidemment ce n'est pas une loi gravée dans le marbre (juste sur mon blog), mais plutôt une forte recommandation. Cette "règle" a d'ailleurs des exceptions qui sont en réalité du bon sens. Elle s'adresse particulièrement aux profils juniors. On est tous passés par là, on veut produire du code beau et performant. Cependant c'est souvent incompatible avec du code réellement lisible. Avec l'expérience on devrait être capable d'identifier assez tôt les bottleneck, les optimisations quick-win etc.