It is a truth universally acknowledged, that the more of a system you open up to customization via plugins/extensions/add-ons, the more damage a malicious plugin/extension/add-on can do. So, sorry, suck it up: extensions will be limited and restricted, especially in as security-critical a program as a browser. But note that, say, programmers' text editors suffer from the same issue. How many of you Emacs users download entire distributions of packages for Emacs without even thinking about it? Have you audited them all? If it can be loaded into Emacs, it basically has arbitrary access to the entire session, and anything your uid has permission to access. We've already seen several malicious npm packages... all it takes is one strategic MELPA bomb and Emacs may not be able to recover from the black eye to its already diminished reputation.

Contrast that with Visual Studio Code, which has a restricted, well-defined API extensions may use.

Oh, and the other thing about restricted, well-defined APIs? You're not locked into your present architecture. You can rewrite the entire code base, and all extensions will Just Work provided you reimplement the extension API. Extensions in the Emacs paradigm of having all system internals exposed to them will break the moment those internals change.

Restricted, well-defined APIs are system design 101.