Sorry, but I have to dismiss this as Obie protecting his economic interests as an owner of a Rails consultancy. I can only guess that he sees negative Ruby coverage like this as a threat to new Ruby development, and thus the future of his consultancy.

With few exceptions, Ruby applications running on MRI will be wholly unsuited to high throughput environments. This is true regardless of how good your Ruby code is. Saying that using Object#kind_of? is bad Ruby coding may be true but it's mostly orthogonal to the speed of the code. Even the most aesthetically pleasing, extensible, and clean Ruby code will be slow.

After a certain threshold of requests per second the bottleneck will almost always become Ruby. After all, it might not even matter how aggressive your caching strategy is if it can take upwards of 50ms to even talk to your cache. MRI Ruby's IO subsystem and its threading model absolutely hamstring its suitability for even IO bound applications.

The good news is that Ruby will improve in the future. For better or worse, Engine Yard hitched its wagon to the 1.8.x generation of Ruby. Engine Yard's customers will be using the 1.8.x series of interpreters for quite some time to come. And Engine Yard has the engineering know how and an economic interest on improving that generation of Ruby.

But in the meantime those of us building applications that need to make efficient use of a given set of hardware are left with a choice. Do we fight with our platform tooth and nail to try and wring even an acceptable amount throughput out of it? Or do we change our platform to best suit the problems in front of us?