That was addressed in the long (and interminable) example thread linked in the article.
Because of RMS's opposition to making gcc usable in any context other than gcc, people just moved to llvm and clang.
The core issue is that these are people who care about FSF, GNU, gcc, etc running headlong into RMS who is forcing design decisions based on a threat that does not exist, leading to the gradual erosion of there relevance.
Take gcc as in the example thread: RMS intentionally hobbling gcc means that gcc is simply not involved in any significant amount of compiler and language research any more. Why bother? it's intentionally designed to make the kind of things that compiler researchers would want to do hard, to "stop it being used in non-free software", similar happens for new languages: why bother messing around gcc where by design your only real option is "compiling" your code to C, which comes with _many_ costs.
These are people who _want_ to use gcc, who _want_ to use gpl, gnu, fsf, etc software, but cannot because functionally RMS does not allow it.
Those people who you speak of that have a romantic attachment towards GCC, are creating their own issues by being inflexible. However, I fail to see how their attachment should be of any serious concern to anybody. Surely, the mature way of dealing with this is for them to learn to let go and vote with their feet sort of speak.
No surprise that the etherium developer (yes, I've looked at yr linked bio) throws in the 'governance' canard, i.e. control software projects through power games, rather than by free association (support a project or fork it).
Free Software is not about governance; it's pretty much a complete antithesis to such power structures. Communities voluntarily coalesce around software projects with a core developer group. Don't like the group, fork the code; don't attempt a takeover/coup and if you do, or agitate for one, then you've revealed your true colours and that community will now see you as a hostile threat to their project.
I work on camera algorithms full time and do Ethereum stuff in my free time, not sure that's relevant though.
Like it or not, FSF has governance and power structures. The GNU project power structure is very top heavy, effectively a dictatorship. I believe dictatorships are bad so I'll continue advocating for GNU to change.
Interestingly the approach to cooperation you're describing (if you don't like it, fork it) is actually the same as OG crypto Bitcoin people. IMO it's not conducive to good outcomes and most of the crypto world has embraced processes that lead to consensus building and more inclusivity (although clearly not perfect yet).
I think you should be more a bit subtle in your analysis and weight the pros and cons. Especially in the context of software projects where nobody gets killed or detained :)
Not saying that dictatorship is the only good way to lead software projects but there are enough highly successful dictator led software projects that it's worth not rejecting this type of governance as just "bad".
On your point about talking about Free Software projects as 'dictatorships', the analogy looks especially silly if you bring it back the other way, which would mean that anyone living in a real world dictatorship could simply 'fork' the country they are living in, recreating/replicating all its lands, forests, cities & towns and install themselves as the new ruling class and attract a new population to people their newly created land. Without any bloodshed; the old 'dictatorship' and its physical lands still exist in a parallel reality and they can carry on along their own original path. Also, people living in these two lands can 'teleport' to the other reality, if they decide they like it better. Doesn't sound very oppressive now, with the analogy properly extended.
It was RMS who "played the governance card" in the first place:
> Emacs is not an independent project, and it isn't governed by its contributors. I'm the head of the GNU Project, and that includes Emacs.
>
> You, as a contributor, can advocate a certain decision, which means you present arguments why I should approve it. I don't need to advocate a decision in that sense.
>
> I leave most technical decisions up to the contributors, including you, because for most of the questions I don't have any special preference of my own. For those questions, I'm happy with whatever works, and I know the contributors can figure out what works.
If you don't like his way of management, you are welcome to fork the project.