One idea for speedups that this article doesn't mention, that I've used very successfully, is splitting an extension into two parts: The Javascript extension that runs in VS Code, and a separate language server[1] written in whatever fast language you desire (without having to compile to WASM).
I do this with an extension I develop, and it works very well. Microsoft even provides a library to make this easy, and sample code[2]. In my case the language server is written in Rust, and uses tree-sitter. This combination feels like a super power. (The first version of my extension was written in clojurescript, using the instaparse parser. It quickly became apparent that it was way too slow.)
A note on my experience with tree-sitter: It's awesome in every way except one. It's so fast that so far I haven't even bothered with incremental parsing: I can do full parsing on every keystroke; and I know that if I ever need a speed boost, I can add incremental parsing. The API is sane and easy to use. The query API is powerful. But the main weakness of tree-sitter is that the error messages are nearly content-free. The most common error looks like this: "(error)". In my case I can deal with that, but I can imagine that for many purposes that's not sufficient. There's been an issue open for 3 years about improving the error messages[3] but I haven't seen a ton of progress (unless I missed it?).
1. https://microsoft.github.io/language-server-protocol/specifi...
2. https://github.com/microsoft/vscode-extension-samples/tree/m...
3. https://github.com/tree-sitter/tree-sitter/issues/255