could it be done without Webassembly?

In theory it could, and in fact, my early attempts near the beginning of this year were aimed at compiling to asm.js. asm.js is a strict subset of JavaScript which lends itself towards compilation, and browsers supporting it will be able to do so and execute it much faster (browsers that don't support it can still run it, just slower). However, asm.js requires aligned memory access (Emscripten docs), and the Perl core does quite a bit of that (for example, one can add -Wcast-align to the ccflags in hints/emscripten.sh to see all the warnings). I managed to get 5.26 patched so that it would at least compile and run some basic code, but at the same time ran into other issues, such as that I was trying to use dynamic loading, which in that combination didn't support dynamic memory expansion. WebAssembly, which you can think of as kind of a precompiled asm.js, does not require aligned memory access, and when I switched to static linking and WASM, things were much easier (relatively speaking), and I didn't have to patch Perl (as much).

So in theory, it would still be possible to do a pure asm.js compilation, if one were to go through the entire Perl core (and any XS modules one wants to add) and change everything that relies on unaligned memory accesses. That's a significant amount of work though. WebAssembly works in any modern browser that supports it, and IMO nowadays requiring a modern browser is no longer a big ask (the days of people being stuck on old IE versions appear to be coming to an end). I also briefly experimented with the WebAssembly "interpreter" that is provided by Binaryen, which would at least allow WebAssembly to be run on older browsers, although probably quite slowly. That might be another option if backwards compatibility with older browsers is required.

Update:

I don't get the purpose of Webassembly here? Is it something like Perl<->Webassembly<->Javascript ?

The perl binary needs to be compiled to either asm.js or WASM, as I explained above. This is because Perl is written in C, and needs to be compiled, "porting" it to JavaScript by hand is basically not an option due to the complexity. Emscripten also does a lot more than that, it provides a virtual environment and standard C libraries that most C programs need to compile and run.

WebAssembly can be thought of like kind of a precompiled JavaScript - they are different languages but run in the same VM and can call into each other - see e.g. "How does WebAssembly fit into the web platform?". What happens when WebPerl loads is basically that there is JavaScript code that prepares the Perl script and loads it into the virtual filesystem, and then the Emscripten-generated code loads and runs the WebAssembly perl binary. Update 2: The WebAssembly perl binary can then call out to JavaScript using the code in WebPerl.xs (which has been compiled to WASM+JS and linked into the perl binary) and its Perl frontend, WebPerl.pm. I explained the further interaction of Perl and JavaScript a bit more here.

A few more minor edits.

I think the idea is that WebAssembly is faster than Javascript, as it's more amenable to a direct translation to machine code.

But to me, it's not a matter of how well the bear dances, but that the bear dances at all :)