確かに速いは定義

何につけても早く処理が終わって困ることはありません。
なのでパフォーマンス・チューニングはし続けるべき作業ではあります。
ですが、それをすることに犠牲になるものがあることも考慮に入れる必要はあります。

罪と罰

パフォーマンス・チューニングによって失うものがある場合があります。
それは、可読性だったり、保守性だったり、生産性だったりします。

例えば、Javaのテクニックで「使い終わった変数には明示的にNULLを入れるとGCがすぐに動いてメモリ節約になる」というものがあり、メモリの少ないiモードアプリ開発ではよく使われました。
ですがこれをやると、関数の最後にすべての変数にNULLを入れるコードを書かないといけなかったので、ソースが冗長になりました。

また、別の例でRubyだと遅いからCRubyにやらせるというようなことをやったことがありますが、CRuby（要するにC言語）の知識が必要になり、ソースコードの管理も別になり、保守が非常に面倒になりました。

使い所が大事

10秒が1秒になるようなパフォーマンス・チューニングなら、多少作りが変でもやったほうが良いと思いますが、10秒が9秒になるようなチューニングにどこまでの保守性・生産性の犠牲を許容するかはよく検討すべきです。