Vyacheslav Egorov (leading Dart AOT & JIT at Google) explains in this comment on Github that this is not clear at all that WASM is a better compilation target that JS.
It is without doubt that WASM is a better compilation target than JS for languages like C/C++ and Rust - languages where you manage your memory manually, where your calls are most often statically dispatched and primitive types are unboxed.
However if you start moving away from this kind of languages towards languages like Dart - which are full of dynamic behaviour, boxed primitive types and GC you will discover it becomes harder to claim with absolute certainty that WASM is a better compilation target than JS - because you would be forced to compile various runtime components (e.g. method dispatch implementation) into WASM - while in JS you get those things from underlying JS runtime and they are implemented natively and heavily optimised.
Another interesting thing to consider is that dart2js essentially benefits from two compilation steps - AOT compilation to JS and dynamic optimisation of this JS later by JS JIT. If AOT compiler fails to statically specialise some call site, there is still a chance that JS VM would manage to do that. You don't get such luxury with WASM.
There are a lot of other factors to consider (e.g. builtin libraries - do you want to implement your own array like structure in WASM with associated performance penalty, or do you just want to use heavily optimised native array?), etc, etc.
That said - I don't doubt that there are workloads and programs that would benefit from Dart targeting WASM. All I am saying is that expecting all Dart programs to magically get faster is incorrect.