(Former Mozilla employee, here)

I'm completely speculating, but it's probably a matter of not wanting to complicate iterating on the translation engine by introducing a bunch of cruft from the Firefox build system (which, though it uses GNU make under the hood, is very much bespoke and complicated).

Since the translation engine is intended to run on a product that hosts WASM, they might as well just build to that.

The upside of using WASM is that the extension itself can be easily ported to other browsers and platforms. The UI uses Firefox specific APIs but the parts that take the HTML from a page and push it through the translation engine would also work in any Chrome-based browser.

(Edit: also free sandboxing of a blob of C++ code that needs to handle arbitrary input from the web!)

The point here is that it simpler to have just one NMT engine in WebAssembly shipped bundled in the extension than runs in all platforms for free, instead of having to support and distribute multiple native builds of the engine that would be sideloaded and communicate with the extension via native messaging.

When the project started for example, the engine has incompatible with ARM, which we could just get for free with WebAssembly. The performance penalty of doing that was minimal for the user eyes, and so far we received less than a handful of complains about it.

Bundling the entire engine on Firefox was never an option for many obvious reasons.

Only Debian alone builds Firefox for 7 different CPU architectures (12 if you count outdated packages too).