Dreamhost had something of a hissy fit because they can't figure out a solid model for deploying simple Rails apps quickly and reliably with minimal configuration (i.e. like PHP). That's because no such solution exists. There are many deployment configurations and every one of them have trade offs in simplicity, correctness, reliability, performance, and widespread support. The simple solutions either perform horribly (CGI) or are extremely unreliable (web server managed FastCGI).

DreamHost has over 10 years of experience running applications in most of the most popular web programming frameworks and Rails has and continues to be one of the most frustrating.

I'm not sure why DreamHost chose to nail Rails specifically. This problem is not new and is definitely not limited to Rails. These same issues plagued the Python web app community for the years I was active there as well.

The B-List does a good job of explaining the history and current situation from a Python perspective:

The fact that the deployment model for the new frameworks centers around long-running processes — rather than launching a clean copy of the application on each request — is one that’s hard on hosting providers; unlike traditional CGI or PHP setups, a framework like Rails or Django or TurboGears simply can’t be run on a “launch a new copy every time” basis; the overhead of loading and initializing the framework makes it unusable in that situation. Having a persistent process which loads the code once and keeps it in memory is the only way this can work.

That's the root of the problem but I fear we've only made things worse over the years with failed attempts at solving it. FastCGI and then SCGI tackled the performance issue but neither solution simplified configuration. Managed FastCGI should have eased configuration but instead creates a bunch of additional reliability issues (orphaned processes, app processes running with web server privileges, etc).

If you want to solve this problem right, I'd say there's really two problems you need to address:

1. Stop proliferation of web / application gateway protocols (SCGI, FastCGI, HTTP).

2. Improve external application process management.

I'd personally like to see FastCGI and SCGI dumped as deployment options and for everyone to move hard on reverse proxy configurations. Most web servers have solid reverse proxy support (lighttpd 1.4 being the notable exception). Using HTTP all the way down has a nice architectural consistency, opens up additional options for caching between web and app, and performs well. If the world moved to this kind of layered HTTP approach, it would open up a lot of possibilities for simplifying configuration and maybe even application discovery.

Managing application processes could be simplified a great deal as well. There's currently quite a bit of fiddling and planning required to get ports allocated properly and to make sure application processes stay up. The whole problem area is begging for innovation.