Disagreements over what it means to be a part of GNU have been a (usually minor) issue for decades.
Well, this issue was much more complicated than that, wasn't it? In this case the role of RMS is more as that f an arbiter.
Apart from that, RMS is the leader of the GNU project. When I submitted my little project to GNU, I first talked to RMS (it was many years ago, o I don't remember the details, but I wrote to some general address and he answered). By submitting my project to GNU, I accepted his leadership, and it was a conscious decision, I knew very well what to expect. Actually, RMS seemed to me quite reasonable and down-to-earth about technical issues, even though I often disagree with him on philosophical issues.
In an ideal world, everyone collaborates harmoniously and no intervention is needed. In practice, clashes do happen sometimes, and under such circumstances the role of the leader is crucial in helping to find a reasonable solution.
I think that the idea that anyone who isn't involved with the project (RMS or otherwise) gets to pick the maintainers of projects, and doesn't just defer to the existing maintainer teams in all but exceptional cases. is untenable (and has been causing unnecessary interpersonal conflicts in GNU for decades), and I hope one of the long-term results of all this is to get rid of that norm.
For an example of doing things pretty firmly in the other direction, I've always liked how new hires on Canonical's OS engineering teams aren't immediately appointed Ubuntu maintainers - they have to go through the same process anyone else would. Of course they have lots of advantages (a full-time job where they work closely with most of the existing maintainers to learn everything they need to publicly demonstrate their fitness for the role), but it makes it clear that the maintainership of Ubuntu is driven by Ubuntu and not by managers at Canonical.