Maybe it is worth considering to make the C3 editor extendable by 3rd party developers instead.
The problem is, stated like this, and to do a good job of it, is an absolutely huge, open-ended project with some pretty nightmarish maintenance considerations. For example in my view to do this properly, we'd need to expose to addons the entire editor UI library, such as tree controls, list views, data tables etc. so editor addons can make use of the same look-and-feel of the rest of the editor and not have to reinvent the wheel for things like a custom editor window with a tree view in it. Every API that addons can use then obligates us to effectively support it forever to avoid breaking backwards compatibility - especially as breaking something that causes the editor to crash on startup has a far higher impact than something that crashes the runtime on startup. In the long-term that can then become a drag on our ability to upgrade the core editor features.
We could bypass that by just giving addons a window to put any old HTML in, but then you likely end up with a bunch of ugly addons with janky looking UI. Implementing quality user interfaces is actually extremely difficult and a great deal of work, and I don't think it's realistic to expect addons to do that for each and every addon. There are also likely going to be complicated compatibility problems anyway - the editor is designed to support only the built-in UI, and is not designed to handle arbitrary HTML injected by addons. There may well be glitches and bugs that happen because an addon inserts some HTML or CSS that does not integrate with the editor. People then assume it's our responsibility to fix such things, which ends up being a nightmare. HTML and CSS also don't have much in the way of encapsulation - although it's better now than it was a few years ago - and so we risk ending up in an SDKv1 type situation with regular breakages as future Construct updates change things.
Then if you want to go in to further specifics, like customizing the Layout View, integrating with the undo system, etc. then you open further cans of worms with compatibility, API design and so on.
So on that basis I would say rather than making an editor system to allow others to implement a 3D editor view, it is actually significantly less work and much easier to support for us to just implement the 3D editor view ourselves.
Other than that, a better approach is to figure out what the smallest possible set of editor features you'd need to have fairly good flexibility for some useful editor features, and request that. For example to address the specific problem of being able to import complex content to the editor, like Spriter animations, we built the Custom Importer API with methods like AddDragDropFileHandler (see the customImporterPlugin sample for a demo). It is far more feasible to support specific cases like that than go for a whole open-ended editor addon system.