Malheureusement non.
Tu prends un cas extrême :) Il n'est pas évident de bien placer le curseur entre du code très lisible mais pas optimal et du code incompréhensible mais plus rapide d'1%.
Mais l'optimisation est l'étape finale d'un développement. Si on constate un goulot d'étranglement dans un workflow, on peut justifier l'utilisation de méthodes "non canoniques", mais optimiser prématurément sans commenter, et ceux qui liront le code plus tard pour le maintenir (c'est à dire soi-même la majorité du temps d'ailleurs) vont se gratter la tête en disant "mais qu'est-ce que j'ai bien pu vouloir dire ?"
Linq en est un parfait exemple : il simplifie la compréhension du code, au prix d'une légère perte de perf, si je me trompe pas. Mais le code étant plus lisible, on gagne du temps de maintenance qui peut être utilisé pour améliorer l'infrastructure du soft par exemple.
J'en ai vu du code, qui faisait des optimisations (qui gratte 1% de perf une fois sur mille) aux petits oignons sur les collections, ça l'a pas empêché d'être bourré de fonctions en complexité quadratique alors qu'elle pourrait être linéaire par exemple.