[citation needed]. Also, relevant Stack Overflow debate is available. [1] TL;DR: yes, of course Ruby is slower than, say, C, but today's bottleneck isn't hardware, it's developer productivity. (Developer time costs way more than hardware.)
[1] https://stackoverflow.com/questions/2529852/why-do-people-sa...
I even did some tests a year or so ago when I was writing a script to merge together data from multiple log files and a couple of databases, including data transformations, merging/collation and sorting of, oh 100GB or so of raw log data a day.
My first tests with Ruby were running pretty slow, so I decided to write the script out as I'd planned in both Ruby and Perl and compare the results on subsets of the data.
I used none of Ruby's OO features, I just did straight simple data structures, hashes and arrays, etc. Ruby has far better infrastructure for dealing with these things built in, and so I wrote the Ruby script in a couple of hours. The Perl script took me a couple of days--admittedly my Perl is rusty, but I wasn't doing anything complicated. But the language just doesn't have as much stuff built in.
Anyway, at the end I had two scripts with exactly the same logic, and I'd even had to implement some things (like Ruby's Array#uniq, which I assume (but don't know) is written in C) from scratch in Perl. So yeah I wasted 16 hours on the Perl script, but you could follow them line by line and they were identical.
Run them one after the other to compare, and the Perl script is literally 100 times faster and uses a tenth of the RAM. I told my Python-loving friends about this and they guffawed at the silly Ruby guy, but it was depressing.
So yeah, Ruby is slow at runtime compared to other languages. Usually that doesn't matter, but sometimes it matters a lot.
Talking about productivity is a good thing because raw "power" doesn't mean anything, but I really wish we could admit publicly that Ruby is really not a race horse. It does other things awfully well and I wouldn't trade language for the world, but man, I wish it could get a free speed jump like Javascript got a few years ago.
Ruby 2.0 and 2.1 made incredible improvements to the garbage collector, a major source of our problem. We determined that it was the speed at which we were creating and destroying objects that was causing the GC to work on overdrive, which drove up CPU usage. So with the new GC improvements, we saw that usage go further and further down.
Ruby isn't a race horse.
It just turns out that when you're just plowing fields, harnessing up your prize stallion is a waste of resources.
The misunderstanding of when an MVC architecture is appropriate, and when to (and not to) use the framework, is the mark of someone who has not yet really understood how to use Rails effectively.
A lot of this is because 1) they jumped on the rails bandwagon without understanding it or if it suited their needs 2) after using rails to prototype their site, they now understand what their architecture should look like and want to start fresh 3) because they've joined the next circle jerk such ask nodejs
All the rest of your post is overly vague, or simply untrue. People pick rails because it has sane defaults eg. ActiveRecord but there are plenty of other gems for other database persistence layers.
That's until you try to scale things.