How to improve performance?

おいらが読んでいるメルマガに以下のような記事がありました。

画面表示が想定外の遅さ処理見直し「1秒の闘い」に勝利
http://itpro.nikkeibp.co.jp/article/COLUMN/20100308/345466/

冒頭には

1. 新営業店システムの開発中，画面の表示が予想以上に遅いという問題に直面した
2. 2カ月間，原因を特定するため地道に対策を検討
3. 「頻繁にキー入力情報を取得する」ロジックが盲点，適宜省略し解決

と書いてあります。
詳細ページは会員じゃないと読めないかもしれないので、解決までの経緯を少しピックアップしてみます。

まず目を付けたのは，プログラムに埋め込んだログ出力の処理だった。
「これが積み重なって処理を遅くしているのではないか」という仮説から，ログ出力処理を業務上必要最小限のものだけに絞った。
これは一定の効果を示したが，「旧システムのスピードほどには改善しなかった」
描画命令の発行回数を減らす，画面制御にかかわる機能を改良する…。NEC内でさまざまなアプローチの検討と実験が続いたが，いずれも改変の手間がかかる割には効果が小さい。
「高速表示を期待できるJava以外の技術で（クライアント・ソフトを）全面的に作り直すことも考えたほどだった」と当時の“行き詰まり具合”を明かす。
プロジェクト・ルームではほぼ毎日，対策の打ち合わせが重ねられた。
2カ月が経過した11月ごろ，アプリケーションの内部構造に潜んでいた問題がようやく見えてきた。

この記事を内容を読んでどう思いますか？
おいらの場合、

「プロファイラは使ったの？まさか２ヶ月間ずっとひたすら試行錯誤してたわけじゃないよね？？」

というのが感想でした。

パフォーマンスチューニングのセオリーは「プロファイラでボトルネックを確実に特定する」ことです。
あてずっぽうにボトルネックを探しまわったり、システムを改造しながらいつかパフォーマンスが改善されるのを期待するのではありません。

開発言語はJavaみたいですから、フリーでも出来のいいプロファイラがいっぱい揃ってると思うのですが、この記事にはプロファイラの話が全く出てきません。
NECって大手でしょ？誰もプロファイラを持ち出そうとしなかったとは考えられにくいのですが・・・でもこの記事からはプロファイラを使った気配はうかがえません。

さらにいうと、画面のレスポンス速度はきちんと定量的に要求定義されていたのでしょうか？

1画面の表示にかかっていた時間は平均2.2秒。この数字だけではピンと来ないが，「スピードが要求される銀行の窓口業務においては，使い物にならない遅さ」（奥田氏）である。目標速度は，旧システムと同程度である約1秒。三井住友銀行と開発ベンダーであるNECは，2秒から1秒へと半減させる「1秒の闘い」に挑んだ。

って、おいおいおい！！こんな話ってカットオーバーしてから闘う内容じゃないと思うんですけど。
「スピードが要求される銀行の窓口業務」って書くぐらいだから、要求定義、設計、開発、システムテスト、いずれのフェーズでもレスポンスは本番環境を想定しながら最重要事項の一つとして扱われてきたはずですよね？？ね？ね？

しかもこの記事って結局「このシステムの場合はこれが原因でした。こんなに大変でした。」という情報をたれ流しているだけで、世間一般のシステム開発にいかせるような教訓を全く導けていないと思います。

というわけで、おいらにとってこの記事はベストプラクティスではなく、アンチパターンにしか見えません。
これはちょっと記事のレベルが低いと思うな〜。

P.S.
ちなみに実を言うと、パフォーマンスチューニングのセオリーについては以下の本の受け売りです。。。