The big pull of go for me is AOT compilation to native code (which translates to fast start time for command line utilities), close integration with the OS,support for value types, and stack allocation.
These are not currently available on the JVM (although this may change as of JDK 8).
I think Java supports escape analysis on loops and will actually allocate stuff on the stack if it's in a tight loop. Your other points are valid; this is more a curiosity than anything else.
I'm aware of real time JVMs, but they seem to target smaller scale mission critical applications (I'd imagine embedded or Scada?)
None of these are free (or "open source" in the OpenJDK sense -- e.g., where most of the system with the exception of a few libraries is open), however, with the exception of the last -- where the first revision was available as part of Jikes RVM.
The only commercial JVM that I do believe has some production server-side deployments -- Oracle's JRocket -- still doesn't support value types and has (in many cases) actually performed worse than HotSpot with large heaps.
So to put it bluntly none of these fit "I'm willing to deploy this to thousands of nodes in production" criteria. To me HotSpot (due to its stability, performance, and support for concurrent GC) VM is more of a reason _to_ use Java/JVM languages -- otherwise I'd much rather use C#, F#, D, Go, or OCaml.
Finally, I should it's quite possible to do manual memory allocation, bypass bounds checking, and to control memory layout using direct byte buffers and Unsafe in HotSpot/OpenJDK. Problem is (and I've mentioned it) is that it incurs serialization costs from copying objects to these byte arrays. Of course may this may be acceptable for many kinds of application, especially if only a _small_ part actually needs this (which I'd imagine describes many -- if not most -- kinds of applications).
Cost is an issue if you're deploying on large scale. The fact the source is not available is an even bigger issue.
OTOH if using a proprietary solution ($$ and closed source) was fine, I'd personally go with C# or F#. If you're fine using a closed-source runtime, why not just use a better language (not to mention Microsoft's products are free for startups via BizSpark)?
Because Mono is not a solution when you need high scalable servers running in commercial UNIXes, z/OS and similar systems? These type of solutions always get to use C++ or Java in our projects.
My current project is actually done in C#, but it is a 100% Microsoft stack.
These are not currently available on the JVM (although this may change as of JDK 8).