Generally, yes. For large applications, having them load all their dependencies on every run is wildly inefficient. For tiny little apps that don’t load a bunch of extra junk, it may be fine. e.g. if you just need to serve out one tiny API endpoint and you can write a Perl/Python/Ruby/PHP script that runs in a few milliseconds, then it may make sense to use CGI (but an app server probably isn’t notably worse than CGI in those cases, either…it’d be about balancing CPU vs. memory usage).
No. FastCGI can not run CGI scripts. It requires applications built to communicate via the FastCGI protocol, which is not the CGI protocol. A CGI script is not a FastCGI script without a wrapper. We provide a wrapper (fcgiwrap), so you can run CGI applications on systems that don’t have suexec available, but it does not mean FastCGI is running CGI scripts. fcgiwrap runs CGI scripts and communicates with the web server via the FastCGI protocol. It is the application server in this context.
No. I deny that. What gave you that idea?
Where do you see a PHP CGI module?