I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation.
It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes that could happen at any "eval()" point.
What you just wrote is exactly what I've been telling people about every new "Python" implementation for the last 3 years. Believe me, I understand this argument completely, that's why I made sure we had all the hard bits (monkey patching core classes, eval, etc.) before I released this.
1) Note that the post doesn't sell its speed; all it says is that they are interested in a high-performance Ruby
2) Python is a very similar language to Ruby, and Pypy already runs python very rapidly. This doesn't guarantee that the Ruby interpreter will be anywhere near as fast, of course, but it does give evidence that it's possible.
3) As kingkilr notes below, they've taken into account your argument and they believe they've implemented enough of the language to be confident that they can run it rapidly. No reason you need to believe him, but it's worth listening to.
It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes that could happen at any "eval()" point.