If you need a lightening fast API, anecdotal evidence suggests you just can't get it down to the speeds you see with Go. Rack/Ruby just isn't going to cut it.
For concurrency-testing-alone it might be not. If it works good at it, then it's a good indication that the concurrency model implemented in the language is not flawed and if there is a problem, then it might be somewhere else in the language.
So that benchmark it's still valuable information in the sense that tells you that that particular language running on that particular runtime its not intrinsically bad at concurrency.
In this particular case (JRuby) moreover, the language gets its concurrency layer thanks to Java, so I'd go really easy with that, unless you really want to say that Java is bad at concurrency or that this is not known and thus a "Hello World" example would not show it.
Which are both wrongly proven statements.
Nonetheless I must admit though that some of those combinations of runtime/server/frameworks are admittedly unstable to replicate or to work with in a real scenario.
http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...