There's nothing here that says that the project in the article is faster than Vim, just that it runs in the browser. To answer your original question: VSCode's internals _already run_ in the browser, so compiling them to WASM for the purposes of portability is moot.
To answer the question that you implied ("why can't vscode be compiled to wasm for performance"): vscode is built at least in part on dynamic languages. There's no compiler for JavaScript (or Python, or Ruby) to WASM, you can only compile the interpreter for these languages to WASM and then run your code in the compiled interpreter. This would be slower than what exists today because it's not replacing the traditionally-slow bits with WASM, it's replacing the fast, native bits with WASM.
The reason there are no compilers for dynamic languages is the same reason you can't compile (the full, canonical) JavaScript/Python/etc. to native code: the dynamic nature of the language prevents the generation of efficient CPU instructions. You'd need to do one of a few things:
1. Rewrite the dynamic code to not use the features that do not compile well to native code. Then write a compiler to compile the efficient subset of your language to native code. This is hard and bad because why use a dynamic language in the first place? You can see examples of this in projects like AssemblyScript and LLJS (for Python, see RPython).
2. Compile everything you can to efficient native code, then make the dynamic bits use less efficient code that does work at runtime that other languages could do at compile time. This is AOT compilation, and building an AOT compiler is hard. Building an AOT compiler that works well for most code is extremely hard. Additionally, you couldn't do things like load dynamic code at runtime (e.g., plugins).
3. Write a compiler that interprets the dynamic code at runtime, and dynamically compiles that code to native code as it is able to identify bits that can be efficiently run on the CPU. This is JIT compilation, and building a JIT compiler is hard. Moreover, you can't do JIT compilation in WASM because it would require WASM to have an API for this, and that seems unlikely right now.
4. Just use a different, more efficient language.
So to answer your question, "why not compile vscode to wasm for performance improvements?" You could, but it wouldn't be faster. Or, you'd rewrite it in a different language, but then it wouldn't be vscode anymore.
That's all a bit beside the point. VSCode is written in TypeScript, and there's no easy way to compile TypeScript to Wasm as it is designed to rely on a full JavaScript runtime.
Your benchmarks are analogous to
Toyota on highway 0-60 8sec
Porche on highway 0-60 3sec
But
Tell me how they perform with load, bumpy terrain, tyre wear.
Just because something runs faster on WASM doesnt mean u have to use it, there are othet things to consider to see if its even worth it. Vscode is based on mono and is written on top of JS/TS. Why woukd you compile it to something and run it on top of WASM, rather than just running it using the native browser engine.
You can even use the VSCodeVim extension (minus neovim-powered features) inside it. You can turn on Settings sync and it will share as many extensions as it can with your Desktop setup, and also your theme and other stuff.
VSCode.dev has a really cool Theme Playground. For instance, if you were curious to see what my current "synthwave-inspired" theme that I like to use looks like (with a variety of different file types open): https://vscode.dev/theme/jaredkent.laserwave
The more interesting and generally most useful way to get to VSCode.dev is from GitHub or Azure Repos. Use the keyboard shortcut "." in a repo file listing to open that Repo on the web in VSCode.dev (or GitHub uses GitHub.dev but it is the same VS Code tech).
