My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.
For my emulator stuff (mostly bit twiddling on integers: https://floooh.github.io/tiny8bit/), I saw a very slight improvement of WASM vs asm.js on browsers that have special handling for asm.js (in the meantime I have dropped asm.js, and only compile to WASM, since all browsers support it).
On iOS Safari (which I guess doesn't have special asm.js handling) WASM is a whopping 3x..5x faster than running the same code compiled to asm.js.
The question now is how much slower 'idiomatic, handwritten Javascript' is on iOS Safari versus the same code written in C compiled to asm.js, but I think another 3x..5x slower is realistic.
From the look of it, in Node.js, WASM suffers less data exchange overhead while been decently close to performance of the native addons.
I may be out of date here, but IME neither JavaScript nor WASM is any good for actual "number crunching" (i.e. statistical or scientific code). For that, you want at least a compiler/language that uses the latest SIMD instructions and lets you choose 32- or 64-bit floats. Better still, you want one that automatically parallelizes loops (you may need to align your data), gives you cheap GPU access, and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.
Modern JS engines are pretty good at speeding up the weirdness that is JS, so maybe WASM will only have small benefits, but using either for numerical work would be making your life unnecessarily hard.
GPU access is about browser APIs rather than being something tied to WASM. We have webgl now and it seems like there's more coming hopefully (https://github.com/gpuweb/gpuweb).
>and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.
Reading WASM seems easier to me than reading real assembly, so double-checking a WASM compiler's output seems much easier than double-checking a native compiler's output. Of course it's on the compilers to support WASM well, but hopefully that simplicity aids them too.