世間を賑わせてるようですが．．．
「問題は何か？」ってことを質問者自身が理解できてないように感じますねぇ．
ストアドストアド言うけどあなたの言うストアドって何よ？
みたいな．
なんかいろんな論点というか比較項目をごっちゃにしたまま議論してる印象．
その辺をちょっと書いてみようとか．
元の質問だと RDBMS は Oracle ということなので，ストアドってのは PL/SQL で書くことを想定してると仮定して．
その PL/SQL ってのは Oracle 独自の言語処理系 (？) の名称だと思いますが，これを一般化した言い方をすると
「埋め込み Ada」
です．たぶん．
Pro*COBOL が COBOL を母言語として SQL を埋め込める言語処理系であるように，Pro*C が C を母言語として SQL を埋め込める言語処理系であるように，PL/SQL ってのは Ada を母言語として SQL を埋め込める処理系です．乱暴？ (^^;
んで，元質問者は Java に SQL を混ぜて書くのはイヤ，ストアドなら全部 SQL，みたいに考えているように見えるのですが，PL/SQL だって実は全部 SQL じゃなくて，Ada に SQL を混ぜて書くというわけ．
つ・ま・り
と考えることもできるわけ．
PL/SQL は「埋め込み Ada」なので，母言語である Ada に SQL を埋め込むことができます．
しかし，それは静的な SQL のみだったはず．少なくとも Oracle 8 の頃はそうだった．
問い合わせ条件なんかが実行時に動的に変わる場合は PL/SQL であっても SQL を文字列で組み立てて実行します．
動的 SQL ってやつね．
その際に文字列を SQL として実行してもらうための方法を CLI (Call-Level Interface) なんて呼んだりします．
Java における標準的な CLI が JDBC です．
んで，元質問者は暗黙的に「Java で CLI」と「ストアド (PL/SQL) で埋め込み SQL」を比較しちゃってるように見えなくもない．
ですが，実際には PL/SQL でも動的 SQL は CLI 的に SQL を文字列で組み立てるわけです．
一方，Java でも埋め込み SQL を使うことは可能です．
そう，SQLJ．
使う人はあまりいないだろうけど (笑)，SQLJ の提唱元 (たしか) でもある Oracle は今でも SQLJ をサポートしてます．
今見たら，Oracle Database 10g R2 用の SQLJ もリリースされてますよ♪
さらに！！
SQLJ は SQL99 の一部でもあります (たしか)．
そんなわけで (どんなわけで？)，SQLJ で書いたコードは (Java の部分も含めて) 全部 SQL！！ (^^;
ともあれ (JW)，
なんて比較は成り立たないわけね．排他的じゃなくて補完的な関係だし，母言語とは直交しているのです．
つ・ま・り
SQLJ (埋め込み Java) vs PL/SQL (埋め込み Ada)
＋
JDBC (Java CLI) vs EXECUTE IMMEDIATE (Ada CLI)
と考えることもできるわけ．
S2Dao みたいに内部的には CLI だけどそうは見えないやり方もあったりするしね．
でもまぁ，なんたってストアドの一番の特性はそれが RDBMS 上で実行されるってことですよね．
でもでも，それって Java と PL/SQL とはなんの関係もない話．
例えば Oracle Developer なんてツール (に含まれていた Oracle Forms だっけ) を使うと，PL/SQL で GUI アプリを作れたわけで．
Oracle Application Server の前身 (OiAS の前の OWAS の前．．． なんだっけ？) では AP サーバ上で PL/SQL で書いたコードを実行できたよね．
HTML 文字列を組み立てるためのパッケージ (Ada 用語) もあったなぁ．
今どうなったかは知らないけど．
一方，Javaでストアドを書いて Oracle 上で実行することもできちゃう．やったことないけど．
JDBC だけでなく SQLJ も使えるらしいよ．
ともあれ (JW)，言語とそれを実行する位置は直交しているのです．ある程度は．
つ・ま・り
と考えることもできるわけ．
それからパフォーマンス．
普通に考えるとストアドの方が有利なのは間違いないと思うんだけど，それってデータのあるところで SQL を実行できるからですよね．
そこで発想を変えてみる．
データのあるところに SQL を実行するプログラムを配置するのではなく，SQL を実行するプログラムのあるところにデータを配置する．
そう．
Oracle TimesTen In-Memory Database．
ディスクを使わず，全てのデータをメモリ上に展開する RDBMS です．
こいつをアプリサーバ上で Oracle Database のキャッシュのように使ってみる．
そのための「Cache Connect to Oracle」なんてプロダクトもちゃんとある．
使い方にもよるだろうけれど，たぶん Oracle Database 上のストアドより速いと思うよ．
なんたって，プロダクト名の「TimesTen」って「Oracle の 10 倍速い」って意味らしいし．(^^;
ちょっと遊んだ範囲だと，10 倍どころじゃなくて 1000 倍くらい速い感じだったけどね．
つ・ま・り
AP サーバ上で In-Memory DB vs DB サーバ上でストアド
と考えることもできるわけ．
．．．
ふつー考えないか．まぁ，これは個人的な趣味ってことで (苦笑)．
さて．
元質問者の比較に戻ると，
になっちゃってるんだよね．
んで，一番大きな課題はメンバーの SQL のスキルみたいなんだけど，それって上の比較とは全く無関係という (苦笑)．
クライアントサイド (AP サーバ) だろうが，サーバサイド (DB サーバ上，ストアドね) だろうが，SQL のスキルは等しく必要．
CLI だろうが，埋め込み SQL だろうが，SQL のスキルは等しく必要．
Java だろうが，Ada だろうが，SQL のスキルは等しく必要．
さて，問題は何だったのだろう？
