で、Seamっていいの？

個人的にはお勧めしません。全然サクサクじゃないし。

APサーバ再起動しなくてもOK！と強調されてますが、クラスローダーがロードするファイル（.classとか.propertiesとか）の変更を反映するには再デプロイが必要で、(JBossAS5を使っていますが)再デプロイが30秒ほどかかります。tomcat+軽量フレームワークなら30秒あればサーバ再起動できるんじゃ？
viewのxhtmlだけは再デプロイなしでサクサク反映させられて幸せですが、seam-genで作ったbuild.xmlにはxhtmlだけ反映させるモードがないのでtarget追加が必須。

今回Seamを採用したのは

EJB3を別APPで使っているので再利用したい
今さらStruts1.x系は不可（←とはいえ2.xの日本語対応にも不安が…）
できれば標準技術のJSFを使いたい

という要望があったからです。（しばりがなければ…Javaでは作ってないです。規模が大きくて階層単位で分業したいとか、MessageDrivenBeanで非同期処理するタスクがあるとか、複数DBにまたがるトランザクションがあるとかでないと…）

ただ、JSF+EJB3を使うという前提であれば、確かにSeamを使わないより使った方がいいと思います。
開発効率も悪くない、というよりむしろ、いい、と言える気が。
とにかくStruts1.x系等に比べて隠蔽されている部分が大きくて学習効率が良いです。書いてて思ったけれど、学習効率の高さこそがSeam最大の利点のような気が。Struts1.x系の頃、JSP,ServletAPI,JDBC,Struts,etc...といろいろ知らないと開発できなかったのが、Seamでは最低限知らなければいけない分量がずいぶん少ないように思います。JSF+EJB3の他にSeamを知らないといけないんじゃ、と突っ込まれそうですが、SeamはJSFがうまくやってくれないところを上手にカバーしているのですよね。
JSF(Facelet)はうまくハマればJSPより断然速く実装できますし。