It is important to understand that CGI is a standard definition of how an information server passes data to a separate program.
The Common Gateway Interface (CGI) is a simple interface for running
external programs, software or gateways under an information server
in a platform-independent manner. Currently, the supported
information servers are HTTP servers.
The interface has been in use by the World-Wide Web since 1993. This
specification defines the interface known as `CGI/1.1', and its use
on the Unix(R) and AmigaDOS(tm) systems.
In the standard model, the web server starts the external program each time it needs one, marshals the data into the standard format and passes it to the program [either as part of the environment, or via the external program's Standard input, depending on the HTTP Method (GET, POST, etc.) used. The program processes the data, returns it's data by printing headers and content to Standard Output, and then exits.
The main drawback to CGI has always been the expense of starting the external program on each invocation. On Unix, this requires the web server to create a copy of itself in memory (fork), and then have the external program overlayed on the copy (exec). The fork/exec cycle is computationally expensive, especially when you're talking about a large Apache process (multi-MB memory footprint) overlayed with a Perl interpreter, which then needs to parse the Perl program before it can be run.
In order to remove the fork/exec cycle from the equation, a couple of new things were developed. Mod_perl embeds the Perl interpreter into the apache process, removing the need to fork/exec on each invocation, and also allowed for caching of parsed perl programs. Numbers reported by various organizations put the increase in throughput at anywhere form 20 to 100 times more than CGI.
A second method, called FastCGI was also developed around the same time. In FastCGI, an external program (often a container, or an application server) is started at the same time that the http server is started, and the http server proxies requests to the FastCGI process. This model provides the same benefits of removing the fork/exec cycle, and has a set of pros/cons that are different from mod_perl.
In the end, CGI/FastCGI/mod_perl, whichever you chose, your program had to understand how to get at the data passed to it by the web server, and that's the crux of the matter, nearly every post-CGI technology defines it's own way of passing data to/from the program (the GI in PSGI still stanbds for Gateway interface), but provides an adapter to convert it's preferred way, to the CGI model, to help make adoption easier.
I'm not sure if I've answered your question at all, but thanks for asking it. I enjoyed writing this answer ;-)