Il faut voir aussi que, pour les langages généralistes (comme C, C++, Ada, ... et même Java), les compilateurs sont aujourd'hui beaucoup plus intelligents qu'avant (pour Java, c'est surtout la machine virtuelle pour être exact). Ils sont souvent capables d'optimiser le code généré de façon absolument incroyable.
Sauf que... les techniques d'optimisation les plus puissantes fonctionnent généralement par "motifs" (ce qu'on appelle les optimisations à lucarne), et les fabricants de compilateurs n'implémentent que les motifs les plus courants (pour un tas de raisons : parce que c'est du code en plus dans le compilo à écrire, à maintenir, ..., donc ça coûte plus cher, et puis ce n'est pas la peine d'implémenter une optimisation qui ne va servir qu'une fois tous les 5 ans).
Résultat : pour que le compilateur génère le maximum de motifs connus avant optimisation, il vaut mieux écrire son code le plus proprement possible, c'est-à-dire sans optimisation ou astuce au niveau code source, ou, si tu préfères, le plus proche possible d'un langage algorithmique. Et puis plus le langage est de haut niveau, plus les potentialités d'optimisation sont étendues. Par contre, le goto et les pointeurs (pour ne citer qu'eux) sont des outils de bas niveau, qui sont difficiles à optimiser lorsqu'ils sont directement utilisés dans le code source.
De plus, ce qui coûte le plus cher aujourd'hui (de très loin), ce n'est pas l'heure de CPU, mais l'heure de développement. Donc cela coûte beaucoup moins cher de moins optimiser au niveau source, car le développement du code d'une part, son débogage et sa maintenance d'autre part coûteront aussi moins cher.
Enfin, je dirais que c'est aussi une bonne chose que les gens globalement essaient moins d'optimiser leurs sources, car peu d'entre eux mesuraient vraiment le résultat de leurs optimisations. Crois-moi, la plupart des astuces pour optimiser le code à vue de nez, en réalité ne changent rien, voire ralentissent le code.
Une optimisation véritable doit se baser sur les résultats que fournissent les logiciel appelés profilers. Ainsi on peut voir les vrais goulets d'étranglement d'un programme -- et non pas les goulets supposés -- et passer du temps à résoudre des vrais problèmes. Mais hélas, ce sont des outils encore bien méconnus de nos jours.