I don't think I understand that response. If a project is forked that could very well be someone deciding to base their work on another's work without regard to the parent code editor's attitude. I could make my own GNU Emacs fork, for instance, just because I wanted to. I don't have to wait for someone to "step down as maintainer" nor do I have to wait for a project to appear to be unmaintained. I can compete against GNU Emacs by building my variant on the same code. Anyone can choose from the published forks and there is no need for the one maintainer per project approach your comment suggests (nor does one maintainer per project exist).
I don't share that objection to forks; I don't find forks to be a problem. One can't do anything to change in the free software world, nor would I want it to change because changing that would mean losing the software freedom I value.
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 don't share that objection to forks; I don't find forks to be a problem. One can't do anything to change in the free software world, nor would I want it to change because changing that would mean losing the software freedom I value.