While WebAssembly MVP is similar in term of scope to asm.js and thus more designed for porting C/C++ apps like games for the web, the first standardized version of WebAssembly is likely to support more useful features like setjmp/longjmp or being able to call directly the DOM or Web APIs. The #1 use case mentioned for WebAssembly is “Better execution for languages and toolkits that are currently cross-compiled to the Web (C/C++, GWT, …)”, and that exactly what Kotlin try to achieve.
That said, since native GC support won’t be part of the first versions of WebAssembly, and given the focus on supporting LLVM -> WebAssembly compile chain, WebAsssembly support is probably more related to the upcoming native environment support recently mentioned by Andrey Breslav.
So what could be the advantage for Kotlin to be a pioneer of WebAssembly?
I think that could put Kotlin in the same position than it has in Android world: a better language that produces optimized bytecode for the platform it targets.
Also being able to make concrete feedback to the WebAssembly community group, and maybe make JetBrains part of this community group to be the leader of the JVM ecosystem in that field. WebAssembly is a moving target, so you could be sure that the spec integrate your core needs in the version standardized at the end of the year. That would be a significant advantage for Kotlin frontend support.
And that could allow you to move faster on the native environment topic by joining forces with “Kotlin frontend” team, since WebAssembly support seems require AOT compilation and maybe LLVM IR generation (since WebAssembly will continue to evolve and since LLVM has first class WebAssembly support, that’s maybe easier to target a well defined format like that).