Mark Mayo has a useful post on FastCGI and SCGI, a kind of an overview of the history. At the end, he comes out preferring HTTP with proxying. I'll throw in my two cents...

Proxying HTTP seems elegant, but I don't think it is any more elegant than FastCGI or SCGI. In reality they are almost the same; you don't lose any information mapping from HTTP to FastCGI or SCGI, and you abstract away a few things that are nice to get rid of. But only a very small number.

One thing that is brought up is the quality of the HTTP implementations. I don't think this is a big deal -- if I understand correctly, a proxied HTTP connection will be cleaned up, and you don't have to worry about the kinds of corner cases that a public production web server needs to worry about. Connections don't die that often, there's some sanity in headers, etc. Putting SimpleHTTPServer or WEBrick behind Apache is probably just fine.

What FastCGI and SCGI provide that HTTP doesn't is a clear separation of the original request and the delegated request. REMOTE_ADDR is the IP address of original request, not the frontend server, and HTTP_HOST is also the original host. SCRIPT_NAME and PATH_INFO are separated out, giving you some idea of context.

These are small issues, but they are important. Without this, you have to do double configuration on both sides of the connection, and passing through information through ad hoc techniques like headers you make up (X-Forwarded-For being a common example).

Which leads to the second issue... what can you trust? Can you trust X-Forwarded-For? Maybe. Can you trust 127.0.0.1? Probably; are you sure you remembered to set that up?

With the *CGIs you get another internal channel of communication for communicating trusted information. A common example is REMOTE_USER, the logged-in user. You don't have to sign it or go through hoops to be sure you can trust it. If it's there, you know that an upstream internal server added it.

These are small details, but I think they are useful enough to make the *CGIs worth it compared to proxying. They reduce configuration, and I hate configuration, and they help avoid insecure and ad hoc conventions for information sharing. At the same time, all three are very similar techniques, and you shouldn't read too much into the decision.

FastCGI has some more features still, particularly process management. I wish I felt like I could confidently use such features, they seem nice. But I also don't think they need to be part of the communication protocol; SCGI is a nice, simple protocol, and the process management might be best implemented separately. FastCGI's heapin' pile o' features is probably its biggest flaw.