The response is right to correct various errors in the original article. But it also misses the point.
Yes, JRuby is fast in comparison to other Ruby implementations. But this says nothing, because in general "normal" C and C++ code can be converted to run on the JVM with similar speed to the original: The JVM (the standard one) is very good at that sort of thing.
But, there are kinds of code that do not run fast on the JVM. Examples of that are self-modifying code. Ruby implementations happen to not rely heavily on that, so running them on the JVM is fast. However, other dynamic languages that are much faster than Ruby do rely on those techniques, critically so.
There has been a lot of effort to bring those advanced techniques to managed runtimes like the JVM, with the goal of running dynamic languages on them quickly. But overall, native implementations are still far faster. For that reason, Microsoft didn't implement a new JS engine on .NET, it wrote a native one, and for the same reason Google is developing a new Dart VM instead of reusing an existing VM (although, that isn't completely true because Dart also compiles to JavaScript, so it can reuse existing VMs, presumably efficiently because the language design clearly shows signs of being optimized to run fast when compiled to JS).
Yes, JRuby is fast in comparison to other Ruby implementations. But this says nothing, because in general "normal" C and C++ code can be converted to run on the JVM with similar speed to the original: The JVM (the standard one) is very good at that sort of thing.
But, there are kinds of code that do not run fast on the JVM. Examples of that are self-modifying code. Ruby implementations happen to not rely heavily on that, so running them on the JVM is fast. However, other dynamic languages that are much faster than Ruby do rely on those techniques, critically so.
There has been a lot of effort to bring those advanced techniques to managed runtimes like the JVM, with the goal of running dynamic languages on them quickly. But overall, native implementations are still far faster. For that reason, Microsoft didn't implement a new JS engine on .NET, it wrote a native one, and for the same reason Google is developing a new Dart VM instead of reusing an existing VM (although, that isn't completely true because Dart also compiles to JavaScript, so it can reuse existing VMs, presumably efficiently because the language design clearly shows signs of being optimized to run fast when compiled to JS).