In this case it's important to note though that this is a necessary side-effect of offering a powerful extension API. If you – for example – install some badly coded extension that blocks the main thread to parse the open file into an uncached AST on every keystroke before rendering the input, that's the extensions fault.

Take my example with an ounce of saltt as I've never coded a VSCode extension. It is very well possible that the extension API prevents this particular example. I guess normally things like parsing source files have to follow guardrails that prevent this kind of bug, or at least discourage coding this way. And ASTs are exposed by VSCode's core for the natively supported languages.

Still, it's probably safe to assume that there is a lot of badly written code out there that does not pay attention to performance, or follows an "optimize-later" mindset.

Features surely often seem tempting to implement in a slow and unoptimized way, and anyone can contribute to VSCode extensions.

Also, size of files. Less of an issue for typical codebases, but VS Code historically has slowed to a standstill on anything remotely large.

I regularly work on a code base with 250k files. Haven't noticed any slowdown

I think the comment you're replying to was blaming slowdowns on the size (in lines of code) of individual files, rather than the total size (in number of files) of the codebase.

To be fair, that's always true; I've managed to make even vim stutter with the right extensions/configuration.

Also, some people are just more sensitive to it than others.