It's also sort of missing the big difference... the JVM is generally superior in performance to the CLR, having a better JIT and better GC performance.
The _real_ big difference is that Java has an enormous open source ecosystem, whereas much of what .NET has is ports or clones of successful Java projects.
That said, I think .NET's probably the better choice for a lot of line-of-business applications simply because the tooling allows for very rapid development of that sort of stuff, and not having easy access to Hadoop or Akka really isn't much of a handicap when you're mostly just banging out a mess of business rules.
Given that, it reads as a list of what the VM can do for you and what you'll need to do yourself in the compiler.
Though the CLR has a lot more "outs", where you can use raw pointers and such. Even put " managed" objects on an unmanaged heap. Don't think this is possible in the JVM. So you can write more C-like code in .net then you can represent in the JVM.
And I don't know if it is possible yet, but for Java 9 Graal is an extension onto of the JVM and can run unmanaged C code alongside normal code, so it should be possible.