The features as plugins model allows the code for a given feature to be kept in it’s own ecosystem.
This mindset is great, however, at the point that a “feature as a plugin” is moved into WordPress Core, it instantly loses many of the benefits of the feature being a plugin.
From a development standpoint, progressing the features of a plugin should move faster than progressing the features in the WordPress Core code.
Also, end users may lose the ability to turn off the feature if an option isn’t added to enable or disable it. Furthermore, simply by having a plugin hanging around in the case that it’s unneeded isn’t very useful either.
If the idea is to create features as plugins, and then merge those plugins into WordPress Core, perhaps we need a second classification of plugins, which are all of the WordPress Core features, which we can install, uninstall, enable, or disable.
In this manner, the features could remain plugins, which is helpful for development. This would also provide a great set of options for optimizing installations by removing unnecessary components.
There would also be a need for identifying dependencies, as to which WordPress Core plugins/features are required for non-WordPress Core plugins to function properly. Also, displaying this information to the user so that they can install the necessary WordPress Core plugins based on these dependencies would be essential.