Part of the problem is that one of Ruby's good sides is that most of the time, it does what you want without requiring most developers to delve into the darker corners of the language. Or indeed care much about performance.
While there are lots of productive, opinionated Ruby developers, the vast majority of us don't know much about the internals of the language.
Heck, for my part I'm working on a Ruby compiler (and have been writing about it for 7 years now... Unfortunately I have far too little time to devote to it), and part of the challenge is that there's no proper language spec and even most people working on MRI does not know the full semantics of the language.
My favourite example of this, is that for a long time during the 1.8.x, the inheritance of one of the core classes was different than what was documented - I wrote an article about the Ruby object model and was "corrected"; except my diagram had been created based on instrumenting the interpreter to verify what actually happened. It was like that for years without anyone noticing (and to be fair, it was a dark corner of the language - very little code depends on the specifics of the inheritance of the eigenclasses of the core classes).
Of those of us who love Ruby and are interested in compiler technology and have the motivation to slog it out to try to get working compilers - whether JIT or AOT - there are extremely few.
And most of that effort is going into JRuby, which is definitively seeing some impressive improvements (e.g. with Truffle) but which a lot of us avoid because of the JVM.
Ruby will get faster. And will get better implementations, but it may still take some time to have much impact.