The CLR may support tail-call optimization, but that's not much. You can have support for TCO in a JVM language, it's just that interoperability with Java suffers.
When comparing the CLR to the JVM, I'm only jealous of one feature of the CLR ... stack-allocated objects.
On the other hand, saying that .NET's support for multiple languages is "equal or better" then that of the JVM is just flat wrong.
The CLR doesn't optimize call-sites where the called method is virtual. This is alleviated somewhat by the semantics of C# (all methods are non-virtual by default), but for dynamic languages it's a disaster. The JVM on the other hand does this ever since Java 1.3 (when hotspot was added as an option).
And the DLR is a cool framework for language designers, but it's one layer above the CLR, and it's just code extracted from the IronPython implementation. And related to speed, if you compare Jython with IronPython, Jython does a lot better right now, although it's not the most active language-implementation on the JVM.
The upcoming InvokeDynamic for the JVM will really kick ass for dynamic invocations ... the JVM will allow one to make calls without knowing the type of the object used in single dispatch ... and those call-sites will be optimized (like method-inlining) just as with a normal "invoke_interface".
And then there's the little things that make your life easier on the JVM ... for example it's easier to generate .class files, or .jar files ... along with debugging symbols. And the JVM is truly multi-platform.
You mentioned tail-calls ... well, the tail-calls in Mono have always been broken and unusable and there's no fix on the horizon. Also speaking of Mono, the GC is not generational and does not defragment the heap. IMHO, it's a low quality implementation that's only optimized for C#.