Technically superior could mean in this case that a rogue plugin does not affect the core editing experience. Having a fixed extension API, if the API is well done, could provide that.
You lose flexibility, you gain stability, discoverability, speed, etc.
I meant superior to Atom and not to Emacs.
As far as I know, the VSCode plugins run in their own process, which makes the editor much more responsive when it loaded many plugins.
I was assuming that Atom extensions were similarly powerful as in Emacs, if that's not the case, then my point is moot.
I agree that restricting what plugins can do can lead to better stability and speed at the expense of extensibility.
From my very limited exposure to VSCode's plugins, it seems they are a lot more limited in how they can change the editor's behavior compared to elisp code in Emacs[1]; if Atom plugins are similarly flexible, then I'm not sure you can say it's (strictly) technically superior if you can only implement a small subset of what you can do in competitor's system. At most it's better at some tasks and worse at others if this is the case.
[1] I didn't say "Emacs plugins" since there is no distinction between user-written elisp code and core editor elisp code and you don't need to create any plugin project or such, which I think makes for a much more organic and pleasant customization experience.