I like this proposal. I think that moving the ui, menu, inputrules, markdown, and schema code into separate packages will make it more obvious what a good code structure for customizations looks like (this is something I struggled with in the beginning). Additionally, copying and pasting lots of code from the core library in order to customize it, often felt wrong to me. Separating these components from the core library right from the start, will hopefully encourage users to mix and match the existing code from different repositories (without having to wonder if this is actually the recommended way of doing these customizations).
Regarding the editor component, model, and transform code I don’t think the same benefits apply as these components will probably not be customized as often. But for these I see the potential benefit of having more flexibility in which versions of the different packages to use. I could imagine that we would want to use the latest editor component in the future while temporarily staying with an older model/transform version in case of backwards incompatible changes. Having these in different repositories should make this easier. Of course this would only work if the editor component does not depend on the latest version of the other two packages (not sure how probable that is).
I suppose the collab plugin would also be moved into its own repository? In our case this would make sense as we are planning to customize it.
I agree with the downsides you listed, but am optimistic that they can be solved by proper documentation.