I can see both sides and I think a balanced approach is best.
First, “You can’t please all of the people all of the time” is very true.
Some apps go for a bare-bones Core to keep it light weight. Users need to use plugins for just about everything.
Some apps succumb to feature bloat in an effort to do everything. The app is heavy, and for most users many features aren’t ever used. The features also present users with a lot of configurations done either by editing files or a complex ACP
IMHO either of these extremes is not the optimal solution.
Perhaps the best way is to have anything not “essential” be a plugin, and when a certain number of users find that plugin useful then consider incorporating it into the Core?
There’s a 3rd approach in the mix too: Features that are implemented as plugins, but ship by default with the standard install (eg, the emoji plugin and the docker plugin)
It depends who is asking for them and how often. If it is a common request (or “everyone always installs the Foo plugin”) across many different, completely unrelated Discourse instances then it should be core.
For example: we made tagging core (essentially “promoting” it from plugin status) since it was used so much and so deeply across so many Discourse instances. It was becoming difficult to even work on as a plugin due to how complex and rich (and highly integrated) the feature set became.
In my opinion, they must be delivered as a plugins But with one core design theme. They may be preinstalled, but I need a couple of big red buttons «Disable this and this, and this, and this».