Quando você está se baseando na experiência? Não é mal. "Toda vez que fizemos X, sofremos um ataque brutal de desempenho. Vamos planejar otimizar ou evitar o X totalmente desta vez."
Quando é relativamente indolor? Não é mal. "Implementar isso como Foo ou Bar levará tanto trabalho quanto, mas, em teoria, Bar deveria ser muito mais eficiente. Vamos barrar isso."
Quando você está evitando algoritmos ruins que escalam terrivelmente? Não é mal. "Nosso líder tecnológico diz que nosso algoritmo de seleção de caminho proposto é executado em tempo fatorial; não tenho certeza do que isso significa, mas ela sugere que comecemos o seppuku, mesmo considerando isso. Vamos considerar outra coisa."
O mal vem de gastar muito tempo e resolver problemas de energia que você não conhece realmente existe. Quando os problemas definitivamente existem, ou quando os psudo-problemas fantasmas podem ser resolvidos de forma barata, o mal vai embora.
Steve314 e Matthieu M. levantar pontos nos comentários que devem ser considerados. Basicamente, algumas variedades de otimizações "indolores" simplesmente não valem a pena porque a atualização de desempenho trivial que elas oferecem não vale a pena a ofuscação de código, elas estão duplicando melhorias que o compilador já está executando, ou ambos. Veja os comentários de alguns bons exemplos de não-aprimoramentos inteligentes demais por meio.