Page Controller は個々の Web ページで何をするかを担うコントローラーだと、PoEAA では説明されています。静的な Web サイトの HTML ファイルをイメージするのは、開発者だけでなくユーザーにとっても理解しやすい単位設定です。
とはいうものの、PRG (Post Redirect Get) パターンの Web MVC フレームワークが主流になったり、REST がパスで表されるものを HTTP メソッドで操作するイメージが広まった現在では、ページ単位よりもリソース単位で認識したほうが合っているでしょう。リソースというのは、URL の R のことです。
Page Controller は基本的に、ドメインモデル全体ではなく、機能と関係したモデル一部だけを扱います。Service Layer を設けた場合、ひとつの Page Controller が参照するのは、たったひつとつのドメインサービスです。それらのモデルを適切なビューに送り出すのが Page Controller の役目です。求められた形式が Web ページであれば Template View かもしれませんし、REST API であれば Transform View と JSON シリアライザかもしれません。
いっぽう、Front Controller のスコープは全ての HTTP リクエストです。PHP のフレームワークを知っている方なら、Web サイトのトップレベルに置かれた /index.php の内容をイメージすると早いでしょう。Web サーバーは全てのリクエストを、いちどそこに集中させます。PHP 以外のものでも、Web MVC フレームワークの多くは、実質的にそれと同じことを行っています。
Front Controller のもっとも重要な役目は、適切な Page Controller へのルーティングです。URL のパスやクエリパタメータ、あるいは HTTP メソッドを見て、適切なアクションへ誘導します。とはいえ、この仕組みを自作することはほとんどなく、ファイル配置、簡単な定義、あるいはアノテーションだけで、暗黙的に実現されている形が一般的です。
意識すべきなのは、HTTP ミドルウェアです。ルーティングの前、あるいはアクションの後に、セキュリティやキャッシュといった、サイトシステム全体に関わることを監視できるのが、Front Controller の持つ特権であり責務です。内部で起きたエラーをハンドリングするのもそうです。妥当なエラーページを表示したり、クラッシュログを開発者に送ったりします。
ちなみに Nginx の location は、ひとつのディレクティブのように見えますが、location / のように書いたときは指定したパス以下の全てに関わる設定になりますが、location = ... と location ~ ... のように書くとマッチしたパスにだけ適用される設定に化けます。