You should consider the scenarios with multiple contributors and single maintainer, where the maintainer is bottle neck.
I am not against the forks, but we also have examples like openwrt/lede split.
My perspective on this is only against splitting contributor base because of maintainer mismanagement.
Edit: in your emacs example, it is much more beneficial your changes (and a lot of others) pushed back to main project vs multiple emacs forks with minor improvements.
This is not directly relevant to the thread, which is about maintainer burnout.
I've used lemacs (Lucid emacs) and xemacs, and now I use Aquamacs.
As I recall, Lucid forked emacs because they, a commercial company with an emacs-based IDE, wanted to push changes faster than the FSF, a small non-profit dependent on volunteer labor, could accept them.
This turned into xemacs. My feeling was that xemacs was much better then emacs-for-x.
I think Aquamacs has better Mac integration than stock GNU emacs.
I am not against the forks, but we also have examples like openwrt/lede split.
My perspective on this is only against splitting contributor base because of maintainer mismanagement.
Edit: in your emacs example, it is much more beneficial your changes (and a lot of others) pushed back to main project vs multiple emacs forks with minor improvements.