I used to work at G. They put this pressure on you artificially, I think because they believe it gets you to buy in to your work due to its importance. Practically, it seems to encourage lethargy because you need to make sure that all billion of them are happy. Great engineering is done when you know what you can sacrifice some goals for other goals.
People today aren't a lot smarter than people were 20 years ago, and we kind of forget that fact when we try to do grandiose projects like "replace the entire stack and make sure that it works equally well to the old stack in all circumstances." The old stack was built well for its goals, and had the benefit of 20 years of tuning. The replacement needs to come when the goals change. There is plenty of opportunity still: peoples' goals change frequently.
If the goal was just to allow you to write webapps using toolchains for native apps, then you can put in an LLVM-like sidecar next to JS that has terrible performance but amazing security (I think this was closest to the goal of WASM). However, if the goal was to bring native performance to webapps means you can target your spec toward efficient JIT compilation on x86 and ARM (and RISC-V), without worrying a lot about portability to other architectures. I have heard a mix of the two looking at the WASM project from the outside: that they wanted native performance with 100% portability of both hardware platforms and development languages, and they thought they could achieve it.
A great TPM (technical program/product manager - the Google term for an engineering-focused product manager) can help define these exclusions, and it sounds like OP really tried hard to get one. I'm surprised that Google didn't give them one to start.
I had the same conclusion: This team needs to get a dedicated TPM to act as a stress umbrella for the team. I tell my engineering team, if anyone is stressing you out, "pinging you" for things, asking you to set up pointless meetings, "escalating" things with managers, or anything else that sucks away your productivity, please redirect them to me and I'll handle these annoyances. If software developers are distracted by stressful bullshit, then I'm not doing my job.
Chrome already had Google Native Client (NaCl), basically the LLVM sidebar you describe, so asm.js and wasm (and even Google's own Dart VM) had an uphill battle to being adopted by Chrome.
People today aren't a lot smarter than people were 20 years ago, and we kind of forget that fact when we try to do grandiose projects like "replace the entire stack and make sure that it works equally well to the old stack in all circumstances." The old stack was built well for its goals, and had the benefit of 20 years of tuning. The replacement needs to come when the goals change. There is plenty of opportunity still: peoples' goals change frequently.
If the goal was just to allow you to write webapps using toolchains for native apps, then you can put in an LLVM-like sidecar next to JS that has terrible performance but amazing security (I think this was closest to the goal of WASM). However, if the goal was to bring native performance to webapps means you can target your spec toward efficient JIT compilation on x86 and ARM (and RISC-V), without worrying a lot about portability to other architectures. I have heard a mix of the two looking at the WASM project from the outside: that they wanted native performance with 100% portability of both hardware platforms and development languages, and they thought they could achieve it.
A great TPM (technical program/product manager - the Google term for an engineering-focused product manager) can help define these exclusions, and it sounds like OP really tried hard to get one. I'm surprised that Google didn't give them one to start.