昨夜、少し勉強してみたのですが、MVCモデルっていいことばかりでもないような？
まず第一に、ファイル数が飛躍的に増えます。
現在の「プランB」は、原則として「１ページ＝１ファイル」です。 Smartyを使っていますが、テンプレートは10個程度です。 ページの種類によって分けているのは3個だけです。
他にAjax関係で呼び出すphpファイルもありますけど、それも10個ない程度です。
D/Bとの接続やPEAR::Auth認証は別ファイルにして、require_once しています。
MVCモデルにすると極端な話、１ページがモデル、ビュー、コントローラーの３つのファイルに分かれます。 モデルは複数ページで共用できるでしょうが、それでも２倍以上になります。
１つのページを作るのに、複数のファイルを開いて作業しなければならないのは、ちょっと煩雑な感じがします。
デザイナーとプログラマーで作業を分担しやすいのはメリットでしょうが、現状では一人で開発しているので．．．
コーディングの量も増えそうです。
今のところ Javascript を除いたPHPコードだけで、１ページあたり600行（80桁換算）くらいです。
簡単なページの場合は、むしろMVCモデルにすると書く量が多くなってしまうようです。
見通しが悪くなるんじゃないかという危惧もあります。
手続き型のよいところは、「順に眺めていけば何の処理をしているか分かりやすい」点です。 出来上がりのHTMLをイメージしやすいですね。
複数ファイルに分かれて「しまう」ことも含めて、スキルがある人でなければ理解しにくいものになりそうです。
最後に、テーブルの INNER JOIN との関連について。
D/Bとやりとりする部分をモデル（M）にしてしまうというのは分かりましたが、現在の「プランB」はテーブルが61個あります。 これらのテーブルについて、いろんな組み合わせで INNER JOIN したクエリを発行しています。
モデルとテーブルが１対１なら分かりやすいのですが、 INNER JOIN の組み合わせごとにモデルを作らなければならないのであれば、ちょっと面倒ですね。
なんてブツクサ書きましたが、それでもMVCモデルに興味を持っているのは、現在の各ページに似て非なるコードが遍在しているのが気になっているからです。
function や class 化すればいいのでしょうが、書いているときはそれが汎用的な処理か判断しづらいです。
「えーっと、この処理はなんかのページで前にやったなぁ。 どこだっけ？」なんてこともあります。
だから、そろそろ書き方を改めたいと思っているのです。
という訳でまだまだ勉強中です。 以下、備忘録。
「てくめも@coop」さんの記事は分かりやすくて参考になりました。 「PHPでOOP」さんのMVCフレームワークのページも、概念を理解するのに役立ちそうです。
「Moonmile Solutions Blog」さんの記事も興味深いです。
ありがとうございます。