The data exchange between host and guest is still unspecified. You can not access host objects from Wasm. Most do just string serialization, which is not fast. Or they write libraries for some particular languages, which damages the universal idea of Wasm. And WASI seems to be quite controversial: https://www.assemblyscript.org/standards-objections.html
Reading though that link is very confusing as someone who hasn't been actively following all of the various standards and organizations in detail. Quite a lot of the technical claims seem a bit vague and hard to evaluate without being more of an expert (like the repeated complaints about WASI being bad for Java/JavaScript/"the Web"). Pretty much the only concrete technical concern I could glean is that whoever wrote that was extremely unhappy about the use of UTF-8 over UTF-16, which I can understand feeling strongly about, but I also feel like the situation where there's a choice between the way Java/JavaScript/Windows does it and the way a lot of other things do it isn't exactly an original problem to WebAssembly. There's merit in the idea of sticking with what a lot of web stuff already uses, but it's not really that crazy to consider that a new standard would be the place where you might try to design with an eye towards shaping the future rather than always following the past.
Moreso than anything technical though, there sure seems to be a lot of bad blood between the group of people behind AssemblyScript and the people behind WASI. This feels like a classic case of small initial technical disagreements spiraling out of control and turning into a larger conflict fueled by personalities and organizational politics. I agree that overall this doesn't add confidence to the WebAssembly ecosystem as a whole, but it's not clear to me that the obvious conclusion is "WASI is controversial" as "WebAssembly seems like it might have a problem with infighting".
"the group of people behind AssemblyScript" is just one person, as far as I can tell from this doc / the relevant Github threads. I wouldn't necessary call it infighting per se, at least not from this interaction.
Wasm has a fundamental problem: int64 is an insufficient data type for real use cases. If you want to create some kind of plugin system based on Wasm, you need to exchange structured data. But most languages disagree about the memory layout. Dynamic languages do tagging, compiled languages do not. And the UTF issue shows that even with strings, there's still no real agreement.
Furthermore, there are now competing interest groups within the Wasm camp. Wasm originally launched as a web standard: an extension of the JavaScript environment. However, some now want to use Wasm as the basis for replacing containers: an extension of a POSIX environment.
reply