で、結局「使う意義」とは

OOによるシステム開発の目的は、派生開発や保守の際の手間を無くす為だと思います。

派生開発の際に膨大なモジュールを一行一行調査して、対象を特定して、影響範囲を調べて、といった途方も無い仕事から解放されたいが為に、対象がどこにあるか分かり易い構成にし、更にメッセージを送り合うようにすることで影響範囲を事前に限定する、といったアプローチなのがOOがこの業界で流行した一番の理由ではないか、と。
スパゲッティソースで辛酸をなめた経験のある人であれば、この作業が以下にエンジニアのモチベーションを下げるかご理解いただける筈です。そして派生開発や障害が発生した際の改修を楽にしようと考えた場合、これは非常に有用なアプローチとなります。

が、なぜか、OOはどこかのタイミングで「開発効率」という言葉を混ぜ込まれたような気がします。
またUMLが流行った頃になると、OOとUMLがまるで同一のような紹介をしている文書を多く見た記憶があります。
オブジェクト指向を語る時は、必ずUMLとそれを使ったOOAの解説が記載され、結局実際のソースコードの足掛かりにすらならない妙なクラスのソースコードが乗っている、とか。

これでは、OOのメリットと使いどころは伝わりませんから、“難しい”とか“よく分からない”という印象しか持ってもらえず、結局は「OOって本当に使う意義があるのか？」という議論に繋がっていくのではないでしょうか？

OOを使った場合の開発効率については、また後日エントリを別途書きたいと思っていますが、自分は常にOODやOOPを使う必要はないと思っています。使うべきところに必要な分だけOOという技法を取り入れてやれば良く、OOのデメリットが目立つような場所には使うべきではないのです。

結局、Method（Functionでも良いですが）の中身は構造化プログラミングにならざる得ないですし、あくまで動くシステムを作る事が目的なのでデザインパターンを駆使するより見やすく分かりやすく保守性の高い実装をした方が全然有意義です。（このへんは、メンバーのスキルとの兼ね合いという側面もありますね）

OOというものの実体が正しく伝わっていれば、こういった割り切りもでき、“難しいから全面規制”とか“OOが全てをぶち壊した”とか、そういった思いを抱く事もないと思うんですけどね。