I'd argue that the main point of WASM is not the performance gain, but that it opens up a fairly straightforward path to use different languages on the web (e.g. it was possible to upstream a WASM backend into LLVM, but if the Emscripten team would have tried to upstream an asm.js backend into LLVM, they'd be laughed out of the room I'm sure - and asm.js also wasn't fast without special handling by the Javascript engine either).
Also don't forget that the above blog post is mostly about "WASM isn't as fast as it should be when using AssemblyScript", which is more of a problem to solve for AssemblyScript than WASM, because when used from C it's fairly easy to get "near-native" performance.
PS: all the disadvantages you're listing (like the linear memory layout) are actually massive advantages (for instance when trying to optimize cache misses) ;)
This isn't WebAssembly being slow the benchmarks just show the overhead of the GC. If you are writing a computationally expensive algorithm in Rust or C++ wasm can be a lot faster but its hard to get close to native performance(i.e. running on bare metal x86/arm).
Our webassembly prototype is about 3-4x faster in raw computation(and that is targeting webassembly exclusively) but has a much higher overhead when interacting with the DOM. That is basically the limiting factor especially on mobile.
> I want to be very clear: Any generalized, quantitative take-away from this article would be ill-advised.
I don't think WASM and JS are "just as fast"--the author only did a couple of microbenchmarks. There are almost certainly many cases in which WASM would outperform JS, but they probably aren't going to be tight loops over an array or similar.
b) WASM is faster today, if done right
c) be faster with WASM with ease ... in the future, after it all and mostly tooling for it, gets stable