Apologies in advance for this being a bit longer.
I believe the issue roots in how the process is structured as well. One thing to remember is that while it is of course hard for the RFC author, it puts quite a burden on every participant in the process. The authors, the parts of the community agreeing, and those who have counterpoints as well. And this burden is not just felt on the Github discussions. It spreads to here, to the subreddit, to Twitter, and everywhere else discussions happen. This then also puts moderation on the spot where trying to slow things down a bit has the effect of taking a side in the discussion. All this creates a long-running circle of frustration with wide ripples.
But I do agree that Github issues are quite bad for these kinds of discussions. It lends itself to certain social dynamics that tend to amplify the bad parts. An RFC author can be overwhelmed by feedback, even supportive ones. Because the discussion might change direction, grow into other related topics, all the while trying to move the RFC into any number of certain directions. This dynamic is occuring in multiple RFCs right now.
On the other hand, from the view of the other participants it also has very draining mechanics. It's hard to be heard if you don't have some big impactful contribution, either in support or as a counterpoint. If you do put together some bigger argument with many parts, you face similar problems as the RFC author. There will be a number of people going on the offensive about your argument. And for each reply you'll get another set of new responses, partially repeating, maybe or maybe not disagreeing with each other as well.
Due to the mechanics in the first paragraph, when you do write a bigger, more nuanced argument, it puts a burden on the RFC author, making it quite hard to fruitfully engage with the whole of the argument presented. So parts will be missed or misunderstood. Which leads to cycles of back and forth that don't tend to go anywhere, since nobody has the breathing room to fully consider and engage.
So as soon as a certain number of participants, arguments or comments is reached, there isn't really much room for the group as a whole to find some kind of consensus.
Then there are the dynamics between the teams responsible for deciding RFCs and the community as a whole. It's not a good use of resources for busy team members to engage with RFCs early on, and they sometimes tend to only fully engage at the end of the process. This leads to a messy "race to a dominant argument" from all sides.
Additionally, there is a problem with precedents and general RFC history. It's extremely hard to find older arguments for a topic that comes up repeatedly. RFCs that come back now and again in some form or another tend to also repeat the same arguments. This is exceptionally draining on all sides of these arguments. It creates groups of people who are either on the offense or defense. The topic of "should this ever be a part of the language/library/etc" is an extremely exhausting one for all sides. It's certainly not fun for the author of the RFC.
Also additionally, the way RFC submissions work in general leads to an everyone-against-everyone situation. With the RFC author being in charge of the primary considered document, everyone is trying to fight for visibility of their ideas and concerns. There are also issues where certain things that an RFC decides are only considered after acceptance. This causes long-running post-hoc arguments in the community. This is not even considering how much happens after-the-fact in tracking issues that never flow back into the original RFC, making the whole process disjoint and hard to follow, as well as hard to predict for anyone participating.
Then there is the whole topic of general power dynamics when you have team members either being the authors of the RFC, or opposing them in the discussion.
I do think recent movements like the MCP approach are going into the right direction. I always thought a bit more formalisation of the process would go a long way. As a rough outline of what I think would be fruitful:
It should start out with a problem statement, devoid of a fixed solution, submitted to the relevant teams. The teams would consider the scope of the problem, if it even is one, what their concerns and constraints are for any solution, and so on. I haven't followed the MCP process too closely, but I think it is aiming for something like this. In my ideal world this would not end up with the submitted problem statement taken as-is. But with a new document outlining the problem space as seen from the teams themselves.
Solution RFCs would be in response to the above outlined problem RFCs. The big difference I would introduce here would be that instead of the author facing an indefinite amount of community members engaging, the responses would take the form of full documents as well. This would allow those opposing or wanting specific changes to organize as well, without immediately burdening the RFC authors. It also gives those with counterpoints breathing room to build up their argument.
A third hard part would be the mechanics of incrementing the solution incorporating the response documents until the relevant teams are satisfied with the outcome. Ideally, this would be done by a team member, as they have the ultimate say about what will happen. They would also be the optimal agents of making sure the problem space is well covered with the solution, and that all response documents were addressed in a constructive manner.
I think the main goal I'd be following is moving away from an everyone-against-everyone system where it's easy to see one side as a winner and the other as a loser. And move more towards a system where one-on-one interactions are either among document authors/supporters (for either the RFC or the response documents), or to get clarification and increase understanding between those groups. Ideally, everyone would focus their "big arguments" on making sure they are well expressed in the RFC and response documents, as those are the points that won't be missed by the evaluating teams or the opposing sides.
It would also make sure that there is a historic timeline of arguments for a specific topic, and that newer discussions can use these old ones. New RFCs could be attached to older problem-space definitions. Those problem-spaces would still have references to the old discussions that weren't accepted and can easily build upon them. Response documents could similarly refer to old discussions, and highlight old response documents that were missed in the new RFC. This would also allow an easier view of how the problem space changed over time. It would also counter the effect of topics going in circles until one side "gives up".
Really simply put: It's the technical topics that should be fighting each other, not the people. I do believe this does align at least a bit with how things are or were planned to evolve, but I don't follow closely enough these days to be sure how much.