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.
> I'll start with heavy number crunching (Go/C) and browser-based apps (JS)
Be careful to distinguish between the language and a particular implementation or runtime environment.
Go, for example, runs perfectly well in the browser[0] except for channels (which are very difficult to implement reliably given the Javascript concurrency model).
If Google decided to allow Go as a language for manipulating the DOM in Chrome, there's no reason that it couldn't serve this role equally well. (This is what Google has done with Dart, so they're unlikely to do it with Go, but this is simply illustrative).