Yeah, people just seemingly realized that there's nothing special about FastCGI that couldn't be done with plain http. And as a bonus, the app itself can work as a server in the dev env, and testing is simpler.
(Only, CGI managed to get headers sorta right by embedding them in protocol vars and not the other way around.)
But I already do this and that doesn't answer the question about the difference between fastCGI and what everyone else seems to be using, but not explaining, is a method of direct integration or ability to talk with the server without CGI/fastCGI.
After doing a little research, it appears this can be done by implementing or writing modules that will talk directly to server internals if I'm understanding this correctly.
You don't usually need to talk to the server from the app. Pretty much the only thing needed in practice is returning an internal redirect that ends up served by another path (with error pages being variations of this). This is solved fine with an HTTP header in the response.
CGI and FastCGI actually have the exact same flow of information as HTTP (to my knowledge). Anything else is either implemented on top of that, or you'll need a module reaching into internal functions.
Both Apache and Nginx can proxy HTTP, out of the box.