I'm not sure at this stage because I'd prefer to see a more complete solution make it into core, and I think that some of those standard features are lacking in key areas.
To give a specific example of this, when using the standard TinyMCE colour buttons (foreground/background) TinyMCE applies a hex colour to the selected element. This is absolutely great for the current user in the current theme, but does not account for the future where you may change your brands colours, or a course/user may use a different theme. You now have content which doesn't work well for your organisation and may be in breach of accessibility guidelines through no fault of the author or anyone else.
What I'd ideally like to do is to have that plugin make use of a CSS or HTML data- attribute, but that's not possible with the current TinyMCE plugin, and the standard TinyMCE plugins don't use standard APIs available to other plugins so we'd have to provide a different solution here.
Likewise a number of people have requested a template-type integration for Bootstrap, but that fixes you to a specific version of Bootstrap which may break in the future. It's one thing for a theme change to break a plugin because that can be fixed more easily, but if the theme change breaks your content then that has much worse consequences and makes it harder for your organisation to upgrade to a newer theme, or a newer version of Moodle.
So, from both a professional (as the person who made the decision not to include those features), and a personal perspective (as someone who cares about both accessibility and making your life easier in the long run) I don't really want to make it too easy to do the 'wrong' thing unless you clearly understand the consequences.
I hope that clarifies my position on this,
Andrew