I'd argue their current plugin API model is far too strict. It only supports 4 things: theming the GUI (color+alpha changes only), adding tree sitter grammars, adding a language server, and adding "slash commands" (which seems to be a defunct prior experiment).
Notably it does not include the ability to add any features, or configure any settings.
In VSCode the block edit function and multi-cursor weren't part of the original tool, but were available as extensions. While Zed has that particular feature right out of the box, there's no ability to add features like that via extensions in Zed.
Also, Zed doesn't even seem to have the concept of per-buffer settings or "effective" settings that differ from what's on disk. It's why you can't set tabs vs spaces for indentation in a single buffer, you can only set it globally (for example). That's probably why they don't allow extensions that do things like add predefined key maps, or associate new files with a language (without defining a new grammar), or apply a pre-defined set of settings automatically (E.g. autodetect indentation type? Vim/Emacs modeline parsing?). Almost all of even the simplest VSCode, Emacs, and Vim/Neovim extensions/packages/plugins make use of this concept, which is why it's wild Zed doesn't even (seemingly) have the concept of it, let alone allowing extensions to use it.
In fact, I'd argue Zed doesn't actually have an extension system at all. It has a completion system (LSP servers), a language addition system (tree sitter grammar and/or LSP server), and a themeing system. It just combines all three into a single list it somewhat misleadingly calls "extensions". But it's missing the ability for "extensions" to do any of the most basic things every other tool assumes is table stakes for an extension system.