But there is a lot of tooling required to solve problems seen by common web apps.
Node is doing it differently, and it has advantages and disadvantages. One disadvantage is if you are doing CPU bound work, you will have to consider how you design your app more carefully. But that's the case with any language or platform.
Event driven servers have been around since the dawn of the internet and the select() call. Node has simply made it easier to write them in a higher level language. I personally think the event model makes a lot of sense for writing network servers, which web servers are. Also having a high performance HTTP implementation built into a platform for building applications for the web is a significant benefit.
I think two prevalent models are going to emerge for writing concurrent servers in the future. Event driven platforms like Node and actor/messaging passing systems like Go and Erlang. The languages and platforms that do not do those things well, I believe, will become less popular.
Ruby developers who care about writing high performance, concurrent web applications aren't going to use Thin unless they're also going to be using an evented framework and libraries. So no Rails, no ActiveRecord. When Thin is used with Rails, it's usually running only one request per process. And I don't think that's very common: Unicorn and Passenger are much more common for request-per-process Rails deployments. Thin is available for evented setups, and Puma is available for threaded setups. Choosing mismatched or less than optimal stacks is hardly a Ruby-specific issue (or one Node avoids in any way other than removing the option entirely), and it tends to indicate either ignorance or a lack of need for the best performance possible.
nginx or Apache are used because they're specifically designed for serving public HTTP traffic, and they have a lot of other features that tend to come in handy. They're also extremely well-optimized for delivering static content. There's no compelling reason to reinvent the wheel there -- HTTP application containers mounted behind dedicated HTTP servers is a serviceable, easily understood model with a lot of distinct benefits.
Finally -- background processing is frequently CPU-intensive. Evented concurrency is generally not useful there. Ruby has great options for both threaded[1] and multiprocess background processes, and the ideal model might not even be the same as what you choose for the frontend.
