横浜の業務用ソフトウェア開発やPHPを使ったWEBシステム開発・ホームページ制作ならアイ・エヌ・ワークスにお任せください。

最近CakePHPなどのフレームワークについて勉強して遊んでいるのですが、最近はViewの部分でSmartyを利用せずに生のphpファイルを利用するのが主流なんですね。（Smartyをオプション的に利用することは可能なようですが）
仕事で何度かSmartyを利用しているのですが、正直メリットよりもデメリットの方が大きいような気がしていましたのでこの方針は結構なことです。

そもそもテンプレートエンジンというものは、デザインとロジックをきれいに分離するために存在するわけです。

で、PHPの場合は require なり includeなりで、内部の処理に合わせて動的にインクルードするファイルを切り替える機能を言語として持っています。
したがって、実はわざわざロジックとデザインを分離するためにテンプレートエンジンに頼る必要はなくて、「ロジック用のphpファイル」と「デザイン用のphpファイル」を最初から分離してコーディングすればOKなわけです。

だいたい、生のPHP自体がテンプレートエンジンとして十分に簡潔な記述力があります。

生PHP : <?= $name ?>
Smarty : {$name}

上と比べて下の方が確かに書きやすいかもしれませんが、まあ大した違いはないですよ。
デザイナーに優しいというけれど、ループ処理のあの妙ちきりんな記述方法を普通のデザイナーさんが理解してコーディングしてくれるとは思えません。
結局PHPプログラマがSmartyの記述法を覚えて、デザイナーに指示をする、あるいはプログラマが直接HTMLに手を入れるしかないわけです。だったら始めからPHP言語で書いたほうが（新しい言語を覚える手間がない分）ベターでしょう。

Smartyの場合、デザインを分離するというより、表示にあたってhtmlを加工する機能がいろいろあることが便利だと受け取られているような気がします。
しかしこれらは単なるライブラリ的な機能ですからテンプレートエンジンであるところのメリットではありませんね。
それより問題なのはテーブルを何重か入れ子にするような複雑なテンプレートの場合、Smartyを使うとデバッグがえらく大変になることです。PHPのデバッガがSmartyの吐き出す複雑怪奇なキャッシュファイル上の行番号を教えるため、間違いの場所を探すのが非常に骨が折れます。
あと、スペルミスなどでassignに失敗したデータを表示しようとするとエラーにならずに単なる空白表示になるのもミスを見落とし易くなり問題だと思います。

まあ今どきはHTML自体はなるべく簡潔にして、デザインはcssで記述するというスタイルが主流です。PHPに限らず、今後はテンプレートエンジン自体の必要性は自然に低下していくのでしょう。

ともかく、私にとって今のところはSmartyを積極的に利用する必然性を見出せません。まあ表示用変換機能の部分は確かに便利なので、誰かがその部分だけを切り出してライブラリに仕立て上げてくれたらいいのになあと思います。（自分がやればいい話かな）