ストラッツ(Struts)って本当にいいの?

　なにを疑問に思ってらっしゃるのか、俺には痛いほどよく分かります(笑)

1.こういう作り方をしていると...
　そのとおりです。
　でも実際のところ、『ＷＥＢ開発』という仕事はＩＴバブル期に一気に一般普及したものであるため、『理解できる人達だけの職人芸』であってはならないのです。
　初心者プログラマーでも、ある程度のものが作れなければいけません。
　サーブレットは少々固定観念の凝り固まりが強い傾向にはありますが、『職人以外には手も出せない』ようなシステムよりはマシなのです。

2.コンテナーが自動で様々なファイルを...
　サーブレットは保守自体も仕事を横割りする前提になっています。
　自動生成されたコードを読むのは、『それができる』人の仕事で、一般の管理者はそこまで厳密な保守をする必要はないというわけです。

3.JSPのカスタムタグをたくさん覚えないといけない
　最近のプログラム言語は覚えなきゃいけないＡＰＩの数なんかも膨大です。
　それに比べれば少ない方だし、カスタムタグの多さは拡張性の高さに繋がるもので、ある程度やむをえないところはあります。

4.なぜ意味もなくフォームにクライアントからリクエストがあるたびに...
　これも開発作業を横割りにするためです。
　より深いフレームワークレベルのプログラムは上級プログラマーが組み、業務ロジックは一般プログラマーが作ることで、効率化を目指しているのです。

5.アクションはなぜ必要なのか。実際コントローラーなのだからサーブレットでもよいのではないか？
　これも４．と同じですね。
　１人の上級プログラマーに過負荷をかけるより、１人の上級者と複数の初心者とで仕事を分担した方が効率が良いからです。

　とまぁ、ここまでツラツラ書きましたが、実際のところこの回答ではあなたの不満は解消しないと俺は確信しています。
　なぜなら、サーブレットは『経営者ウケするように作られたシステム』だからです。

　市販のシステムパッケージというのは２種類あって、１つは『本当に現場のことを思って作られたもの』、そしてもう１つは『経営者ウケを狙って、現場の意見を無視して作られたもの』です。
　実際のところ、システムパッケージに対してお金を払うのは、コンピューターの素人であることが多い『経営者』で、現実的には後者のシステムの方がよく売れるんです。
　ようするに、『ＩＴ経済というものは現場で回ってるんじゃなく、会議室で回ってる』わけですね(^_^;
　それが現実です。

あなたが言っているのは、結局は「車輪の再発明」と同じことです。

深く理解できるから、JSPのカスタムタグのような複雑な機構は不要だから、リクエストパラメータをいちいちJavaBeanに押し込めなくてもよいから、サーブレットで何でもできるから、だから全部コーディングするのですか？

それではプロジェクトは成り立ちません。
Strutsのようなフレームワークは、毎回書かずにすむような部分を提供しているに過ぎません。中にはJSPのように、処理上は迂遠で重いだけのようなコードも含まれますが、それでもStrutsを選ぶのは、無駄な開発コストをかけないためです。

あなたはもしかしたら、Strutsよりシンプルな構造をベースにしたWebシステムを組めるかもしれません。
では次は？また０から組みますか？再利用するでしょう？
その再利用する部分は、結局Strutsと同じか、似たような機能の集合体になりませんか？　ならなぜ、既にあるStrutsを使わないのでしょうか？

Struts登場以前は、各社から似たようなフレームワークが乱立していたのです。オープンソースでシンプル、かつ容易にカスタマイズ可能なStrutsが登場したことで、それらは結局駆逐されました。
駆逐されなくても、結局どこのプロジェクトでも、何かしらのフレームワークは使っていたでしょう。誰も、車輪（フレームワーク）を再発明（０から作り直し）したいとは思っていないからです。

参考書にあるような単純な画面をつくるだけならStrutsのメリットは生かせないでしょう。

ですが、実際の業務では何百という画面を作ります。
そのためにいちいちサーブレットを作っては手間がかかりますし、質問者様のように開発者がみんなサーブレットを理解してるとも限りません。

また、サニタイジングの問題もあります。
Strutsのタグは、多少なりともそこを吸収して、開発者の作業を軽減してくれています。
また、カスタムタグはJSPでスクリプティングを書くことを少なくしてくれます。

できればStrutsのコードを読んで見てください。
実際に使っていても気づかないようなことをしてくれています。
それを毎回開発する手間を考えると、かなりの効率アップになるんじゃないでしょうか。

その疑問点はもっともですので、その気づいた点を考慮に入れたフレームワークを作成してみてください。

例えばどのような形のがよいのでしょうか？

ＰＨＰは自由度がありすぎるので、ＪＡＶＡの方がいいとか、その逆でＪＡＶＡでは敷居が高すぎるとか、いろいろ言われてそれぞれもっともなのです。

例えば、
１は、深いレベルで理解しなくても済むとも言えるのです。昔の人はアセンブラを知らずしてプログラムは語れないといいました。確かにそうでしょう。その後はＣを知らずして、その後はＪＡＶＡ、その後は…。

でも今のシステムをＣで構築していたら膨大な時間がかかってしまいます。

逆に小さいものを作るならフレームワークは不要です。（当たり前ですが）

１つ経験者として言えるのが、struts（他のフレームワークでもいいです）というみんなと共通の約束事があると開発はスムーズに進みます。
でもその代わりルールも増えてしまうのです。

要は個々ではなく、全体としてとらえてみてください。