SQLの重要性
これには、大きな異論はないです。
しかし、またちょっと補足したくなりました。
おそらくここでの上流エンジニアというのは、以前のメインフレームでCOBOLを使って開発する形態がメインの人々のことを指していると思います。
確かにその年代の人々は、SQLが発明される前に活躍されていたので、当時のデータベースというとISAMか階層型あるいはネットワーク型が主流だと思われます。
それらのDBMSは、基本的にアクセス手法は、レコード単位のナビゲーション型が主流でしたので、レコードにアクセスするためのキーを指定して１つ１つレコード単位で処理を進めていくというスタイルが主流だったと思います。（実は、私も20数年前、ある会社の情報システム部に勤めていましたが、その時、COBOL＋CODASYL型のデータベースで業務システムを開発していました。 そういう点では、ここで槍玉に挙げられている上流エンジニアと世代的にはかぶっています。）
そういうマインドの人が大した訓練も受けずに、RDBの世界に入ってくると、従来の発想でレコード単位のナビゲーショナル主体でプログラミング（あるいはプログラム設計）をして、大変効率の悪いデータベースアクセスパターンになってしまう。
ということだと思います。
しかし、SQLの問題は、そもそもSQLというものがSET指向に基づいて設計されているので、逆にナビゲーショナルなアクセスが不得意な点です。
ですので、本来は、ナビゲーショナル処理するほうが楽な場合も全てSQL文で処理しなければならないという逆手間が発生してしまいます。
これは、O/Rインピーダンスミスマッチ問題としてオブジェクト指向開発に必ずついて回る問題ですが、正確には、これはオブジェクト指向型開発を採用するしないにかかわらず、古くからの従来型の構造化プログラミングでも起こりうる話です。
要するに、データベースアクセスを含むアプリケーションの開発には、SET指向のアクセスも必要だし、ナビゲーショナルが適している処理もある。 それらを適材適所に組み合わせることができる処理系が必要だと思います。
O/Rマッパーは、そこを楽にしてくれるツールでもあるわけです。