JPAとかだと実際に動かさなくてはいけないのが敷居が高いかなあと。あとはJPQLも正しいかどうか事前にレビューしにくい。
おいらは必ずSQLをDB管理ツールで動作を確認，それをコードに落とし込むようにしていたので，それにくらべてJPQLはその検証ができないから効率が悪いんじゃないかと思っていたことがありました．JPAでの開発経験が半年以下くらいのときです．
でもJPQLもSQLも同じ文字列です．その文字列を渡して結果を返すことも同じ．
ならばSQLの動作確認をするようにJPQLの動作確認をすればいい．そのあとコードに組み込む．Entityクラスはテーブルの関連が出来上がった時点で完成しているわけですから，確認をするために必要な作業は特にありません．
つまりSQLとの作業の違いはなかったのです．
あとは案件的な制約でDB設計が毎度毎度いじれるのかって話もあります。みんないじれてんのかなあ。
これはどうしようもないですね．政治的な話ですから．
動いているコードにリファクタリングをしてもいいのか，トランザクションスクリプトによって他のコード変更の影響を受けない設計がいいのかとか問題と似ていると思います．
ただ，機能追加などのバージョンアップではいじらないほうがいいでしょう．なぜならすでにその動いているフレームワークやライブラリ選択はその案件に最適なものを選んでいるはずだからです．少なくともその当時はベストな選択だったはず．
数年ごとに新たに作り直しということも多いと思いますが，この場合DB設計も１からやり直すことが多いのでそのタイミングで考慮すればいいだけのこと．DB設計が終わった後でライブラリやフレームワークの選択はしちゃいけないと思います．同時進行でないと．つまり，コードをかけない人はDB設計しちゃだめなんですね．
