2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see Python, JS, Go, all with support for compiling to WASM.
GCs usually need low level system acces in a way that is not supported by WASM for obvious reasons (security, sandboxing, ...). Go also has problems with the way they implement Goroutines if I remember correctly.
WASM will definitely need some kind of GC bridge to make things efficient for garbage collected languages. Potentially with certain primitives exposed that make shipping your own GC efficient. We'll see how it develops.
(2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).
C, C++, Rust, etc. do not fit into that model at all. There's a lot of software written in C, and there's a lot of performance to be gained by dropping down to that level when necessary.
The JVM is (and was from the start) a lot more dynamic than Java.