CはSを呼び出し、SはMからデータを受けとり形成、その結果を受け取ったCがVにデータを渡す。
なので、C→S→M→S→C→Vになります。
このことから、ここで言っているサービスは、汎用処理を担うサービスクラスではなく、アプリケーションをレイヤ化した時のサービス層のことだと考えます。
サービスという言葉は曖昧で、ここは混在されがちなので、まずここはレビューされる方と共通認識を持たれたほうが良いかと思います。
で、このSですが、どういうときに作るべきなのでしょうか？
サービス層の前提で記載しますが、大規模な業務アプリケーション（例えば銀行のシステム等）を開発する時はだいたいこの層を設けます。
理由は大規模な業務アプリケーションだけに業務ロジックが複雑だからです。
各層の役割を明確にし、単一の責任を持たせ、見通して良くして保守性や可読性を向上させる目的があります。
上記の目的から、このサービス層を設ける時は、業務データへのアクセスにリポジトリというデータアクセスにフォーカスした層を設けるのが一般的です。また、この時ModelはEntityと呼ばれることがあります。
Service、Model、Repositoryはアプリケーションのコアとなる層であり、システムの実体や関連性（ビジネス）を表現することから、これらをまとめてドメイン層と呼ばれることがあります。
この時各層の責任分界点はプロジェクトによって異なりますが、だいたい以下のようになります。
Controller
→フレームワークでRoutingサービスに委譲することが多い
→フレームワークでValidationサービスに委譲することが多い
- セッション管理
- リクエストをServiceに適切な状態（Model、Entity等）に変換する処理
- 処理結果をViewに適切な状態に変換する処理
→Controllerをより薄くするためにPresenterに委譲することもある
Service
→例えばECで言うと、在庫がないと注文を確定できない等、ビジネスルールに即して注文確定させるような主処理
Repository
ざっくりな分類ですが、上記を見て、Controllerの役割が多いことにお気づきでしょうか。
本来、Controllerで行うべき多くの処理をフレームワークが各サービス（ここで言っているサービスはサービス層ではない方）に委譲してくれているので、フレームワークを利用するとControllerでやるべきことが少なくなります。
故に、フレームワークを使って、比較的小規模なアプリケーションや業務ロジックがそこまで複雑でないアプリケーションを作る時は、わざわざ新しい層を作るのが面倒なので、この薄くなったControllerに大半の処理を書く人が多いのかと思います。
大規模な業務アプリケーションで利用する言語（Java等）では、言語の特性やフレームワークによるサポートによってアプリケーションのレイヤ化がしやすくなっていますが、PHPもそれに近づいてきていると実感しています。
実際にPHPを代表するSymfonyフレームワークでも、Javaの仕組みをPHPに適応させることでPHPをより良くしていくと言っています。
昨今の変化が激しい時代に、長い目で見て変更に強いアプリケーションを作るのであれば、上記の様にサービスを設けてドメイン層を切り出すというアプローチを取るのも良いかと思います。
ただ、考え方を見直したり、作成するクラス数も増加しますので、検討が必要です。
大事なのは、先人たちが考え出した様々アーキテクチャ（DDD, Clean Architecture, MVVM等）を知って、開発するシステムの特性によってアーキテクチャ使いわけることが重要だと考えます。
Q&A
ベストアンサー
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。