It's not quite as clean-cut as that, though it is self-evident that optimizing at runtime (e.g. JIT) is the only recourse for optimizations that are otherwise reliant on runtime information (e.g. dynamic dispatch/virtual calls). Go does have an advantage over Java in that it prefers static semantics (pcwalton's assertion that Go is "virtual heavy" should likely be taken as relative to Rust/C++), so has less to benefit from devirtualization, and thus less of an argument to go the JIT route (which would take monumental engineering effort).
I believe pcwalton's points are that 1) running in a virtual machine does not imply that a language is slow (though I bet he'd agree with you that JIT introduces substantial memory overhead), and 2) Java, specifically, is not slow, thanks to a highly-tuned JIT.