あまり正確な表現ではないかも知れませんが、次のような感じです。
テーブル単位でクラスを作っているとのことですが、ORMはそのクラスを簡単に宣言的に作れる機能です。ORMでは対象のテーブルにこういう型のこういうカラムがあると宣言的に記載します。中には、テーブルを指定するだけでカラムを自動的に認識してくれる物、または、クラス名から自動的にテーブルまで決まる(「設定より規約」の採用)物やもあります。ただそれだけで、簡単なクエリ、例えば、nameがTaroのレコードを検索して、そのクラスのオブジェクトにしたもののリストが取得する、というのがメソッド一つでできます。ソートやリミットなど、単純な物であれば、同様にできます。
ORMの利点は簡単なクエリであれば、メソッド一つや二つで簡単にできると言うことです。そこにSQL文の記載は必要ありません。よく使うようなソート(order by)やリミット(limit)も用意されていますので、実用性は十分です。リレーションについても、関連することが定義してあれば、簡単にjoinして、同時に取得もできます。また宣言的に定義できるというのも利点です。もし、作成途中の仕様変更でカラムが増えた場合、いちいち作っていたら全てのSQL文で色々考えて変更する必要があるかも知れませんが、ORMでは定義部分に一行追加するだけで済む場合もあります。
ただ、欠点もあります。ORMは単純なマッピングしかできません。ある程度複雑なこともできないことも無いのですが、基本的にはテーブルがそのままクラスになる(カラムとプロパティが1対1になる)ように作らないと、あまり良いものにはなりません(リードオンリーで良ければVIEWに対して作るという手段もあります)。また、複雑なSQL文を作るには限界があります。特にSQL文の書き方によってパフォーマンスが異なるぐらい複雑な場合は、ORMではパフォーマンスがかなり悪くなってしまうこともあります。だからといって、そういう場合にORMが全く使えないというわけではありません。多くのORMはSQL文をそのまま渡して、マッピングだけを自動化するようなことができます。パフォーマンスに影響が出るような複雑な場合のみSQL文を使って、単純なクエリ(例えばnameがTaroを検索とか)はORMそのままを使うとしただけでもいいのです。
ORMにはもう一つ利点があります。それは、RDBMSの実装の違いを吸収できる場合があると言うことです。MySQL、PostgreSQL、Oracle、SQLiteなど多くのRDBMSがありますが、型の取り方や使える文法などに差異があります。SQLiteはお手軽に使えるため、開発やテストなどでは有用ですが、本番環境では性能的に使えるような物ではありません。ORMを使えばそのような差異を吸収できるため、開発やテストではSQLiteを使って、本番ではMySQLを使うと言うこともできます。開発効率が良くなるという話は、こういう面もあるからというのもあります。
なお、ORMで気をつけて欲しいのは、SQLが必要なくなるということではないことです。ORMを使う場合は、どのようなSQL文が発行されるかはデバックなどで常に確認する必要があります。複雑な条件にしてしまうと、時には効率が悪いSQL文を発行してしまっているときもありますので、SQL文を直接読ませるように書き直す必要もあります。ただ、単純なクエリがほとんどの場合であれば、開発効率は高くなると思います。
と言うことで、複雑なSQL文がはたして全体のどれだけを占めるのか、それを考えてみてはいかがでしょうか?また、逆に言うと、複雑なSQL文が必要になるようなDB設計になっていないでしょうか?ORMは万能ではありませんし、システムによってあうあわないはあると思っています。ただ、会計処理など複雑な計算が必要になるシステムでない限り、ほとんどのクエリは単純な物になるだろうし、ORMに単純にマッピングできると私は思っています。