I've been working in Rails on a few projects now, and I'm getting to the point where it's my tool of choice as a developer (as opposed to a sysadmin... I'm still not deploying any Rails apps on my own servers as they don't have enough memory to do it justice). It feels like a lot of overhead, sucking in ten megs or so of code (according to 'du -s vendor/rails' on one project), but it saves huge amounts of time messing around refactoring the backend of the system. In the PHP projects I work on, we spend a lot of time moving stuff around, deciding to structure the project in one way, then later on changing it to work some other way, whereas Rails projects start out with a pretty good default way of doing things and don't seem to need to have it changed much later. routes.rb needs refactoring sometimes, and things get moved from controller to controller, but you don't have to touch the database access code, and so on.
An observation: it's relatively easy to get up and running with somebody else's Rails project, as opposed to somebody else's PHP project, as all the basic stuff is always the same. You can just look at routes.rb to see where all the code is, it's obvious where new controllers/views/models/migrations go, and so on.
One thing I wonder is if somebody's done a cut-down implementation of the 'core' bits of Rails: routing, controllers and views, migrations, and perhaps some parts of ActiveRecord. I'm not speaking from experience here, but I'd guess that with judicious lazy loading and by ignoring anything beyond the basics, you could implement it such that it would have a quick enough startup time to run acceptably as a CGI, or under an Apache module that functions like mod_php but for Ruby, embedding the Ruby interpreter and compiling/running everything from scratch in a new interpreter instance on every request. That would be interesting.