I do understand why people try this approach:

First: wasm is the perfect plug-in language, as it provides a high level of isolation and therefore security for the host app.

Second: the promise of wasm is that you can write it in any language. I think this is compelling for any application that seeks for extensibility.

Wether all this is worth the effort is probably the actual question. Maybe we will be surprised by killer plugins that wouldn’t be possible with regular plug-in systems…

You might be missing the fact that WASM nowadays doesn't necessarily have anything to do with web browsers. It was initially designed for running in web browsers, but in the last few years there's been a lot of activity surrounding embedding WASM runtimes in processes other than web browsers. Mostly the idea is for it to be a way to execute untrusted / customer code (e.g. "plugins") with sophisticated sandboxing, etc.

Wasm has the promise to be a single target for your plugins that could be written in node/rust/python and the consumer won't have to have that specific version of python installed. That and the possibility to sandbox a plugin so my repl function can't also upload my ssh keys would be nice.

WASM doesn't mean this has to be true, but it could be.

It's both dynamically loadable & doesn't require any external dependencies. Each WASM container has its own heap, so you don't need e.g. glibc versions to be the same, which is otherwise a PITA for plugins.

Terminal is just UI. It’s completely orthogonal to WASM.