前回のエントリから時間が空いてしまいました、ごめんなさい。せっかくひがさんとkoichikさんにコメントをいただいたので整理します。
ひがさんのコメントが象徴的だと思っていて、
選ぶことが大事じゃなくて作ることが大事なのでは。
という点で、僕は「選ぶことが大事だ」と思っています。そもそも僕はひがさんやkoichikさんのように「（フレームワークを）作る」力がない（気持ちとか、そういうのも含めて）。
なので、koichikさんの
規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められる＜中略＞の根拠たり得る説得力ある意見が聞きたかった
については、「選ぶ」という視点ではSpringの方が最適化されているからという答えになります（ここまで断定的な言い方をしているつもりはなくて、『そういう場合が多い』というぐらいだけど）。
「規模で世の中の 80% を占めるところのエンタープライズシステム」では、単純にひがさんの言う生産性だけが生産性にはならないはずです。
プロジェクトは様々な環境に置かれています。人員の制約、社内外の制約などなど。ですから、「Webアプリケーションを作る」ことが早いからといって、システム全体の生産性が高いとは言い切れない。企業内、グループ内での生産性を考えれば、もっと物事は単純ではありません。
Springはフレームワークを統合するためのプラットフォームとして作られています。Springの冗長と言われる構造は組み合わせの汎用性を向上させるために必要な犠牲です。銀の弾丸となるフレームワークは存在しません。だから、調整が効くことが重要だと考えています。Spring（と、その周辺）は調整を重視していると思っています。
Seasarを使うな、と言っているわけではありません。SeasarはWebアプリケーションフレームワーク開発に最適化されているし、確かに魅力が多い。Javaエンジニアがさっくり作るのならRailsより早いというのは本当だと思います。なので、Seasarがシステム全体の生産性を高めるのであれば使えばよい。
個人的にはSeasarは使ってみたいフレームワークの1つです。でも、きっと使うならSpringを組み合わせて使うと思います。
ちょっと横道ですがアーキテクチャとフレームワークは根本的に異なっているモノです。
アーキテクチャは「ある範囲のシステムを継続的に維持、成長させるための枠組み」です。世で言うエンタープライズ・アーキテクチャの定義に近い。なので、ITアーキテクトというのは、ソフトウェアだけではなくて財務、人的リソースなど、システムを開発し維持するプロセスそのものを対象にします。とても動的なイメージ。
一方、フレームワークはアプリケーションの構造であり、何らかのアーキテクチャを体現したソフトウェアの塊です。静的なもの。
Seasarは、ひがさんやkoichikさんが考えたアーキテクチャの上に成り立っているフレームワークです。そのアーキテクチャを利用することが大事。フレームワークだけを盲目的に使うのは避けなくてはいけません。
ココまで書いて思ったけど、「そういう風にアーキテクチャを考えられる人も少ないんだよ」と言われれば、その通りかもね。ただ、僕が思うITアーキテクトって、そういう役割です。
