In theory the idea of a meritocracy for a project like GNU sounds appealing: those who do the most work have the greater say in what course to set.
Meritocracy seems to naturally embodies an idea of fairness and inclusion. The problem is that software is not fungible. As such, some projects will be more popular and some less, and also some software will be more successful commercially than other software. If a piece of software is commercially successful it sometimes means that some people can find full time employment maintaining or extending it. This is obviously a great thing. Less obvious is that now, with full time employment, meritocratic decision making will shift heavily in favour of those employed to work on the commercially successful projects. The problem with this is twofold: 1. economic relevance of certain software will gain influence at the cost of less economically viable software, even though from a software freedom perspective the latter might be just as important. 2. people are notoriously biased when their employment is involved. They might not vote in the best interest of the general project. Compounding this is that if some piece of software is really successful, companies formed around this software might employ new people who have no interest in Free Software, but due to their skill can become maintainers. These flaws in meritocractic decision making can be extended to democractic decision making: outcomes can be influenced by popularity or self interest, neither of which has direct bearing on software freedom. To see what meritocracy can result in one has to look no further than one of the most popular software projects under the GPL, which has a governing foundation that cozies up to GPL violators and patent abusers, and has a president that doesn't even use their own software. The current situation for GNU is that there is a chief GNUIsance. A position whose single power seems to be having a veto over what interpretations of the four software freedoms are acceptable for the project. Having a single person in a pivotal position can be an unstable setup, and it is nearly impossible to implement after a project has gained some momentum. Fortunately for GNU, it has had someone to fill the position from the very beginning, who has so far never faltered in their duty of chief GNUisance. As such, the current system has mostly worked and it would be counter productive to try and exchange it at a whim for another system that is either known to be inferior (from a software freedom perspective), or of which the effects are completely unknown, for reasons that are not related to the fundamental role of chief GNUisance.
