You are right, but aren't really attacking the point I was making. Even with totally optimized sql, one language's ORM will be inherently slower than another due to the intrisics of how the records being operated on are represented in that particular language. In Rails's case, EVERY single record pulled out of a database gets its own object. There is overhead to being able to represent table members from a relational database in a language with all of the lovely convenience methods tacked on to the resulting object (things such as treating ranges of records pulled like a hash, for instance.

This is compounded by the fact that ActiveRecord obfuscates much of the sql code you posted above (not always, but in many cases). When a user new to Rails goes in and sees "Oh, all I have to do to set up foreign key relations is to just say this model belongs to this other one? NICE!", it isn't immediately clear what the implications of whats happening under the hood to accommodate that are, and all of the ways which this can quickly be misused to cause a huge performance bottleneck. That syntactic sugar smooths over some of the pitfalls of efficiently interacting with a relational DB.

It's important to note that these things do not make ActiveRecord a bad ORM in and of itself, as many users will not build projects large enough to have to worry about such bottlenecks, but it CAN and DOES cause problems when projects get larger and have to start taking on overhead from the resources allocated for all those records. That is what people are complaining about when they mention Rails doesn't scale well (or at least one of the reasons).