I don't know what the best answer to that potential problem is: I think users should continue to be allowed to comment on any issue.
However I do think that the amount of analysis and effort that the user has done for each comment is relevant.
Silly hypothetical example: if a project is a Fibonacci function that (incorrectly) prints nothing but repeated "1" values, then the potential range of comments may include:
- "it's wrong"
- "it's printing the wrong output"
- "expected to see 1 1 2 3 ... but found 1 1 1 1 ..."
- "line two is missing an addition operator near character five"
- "please see #3 for a pull request to add an addition operator on line two"
(roughly in order of estimated "most frequent" to "least common" comment volume -- and not coincidentally, also ordered from "least analysis" to "most analysis" performed)
Not all participants have the same level of analysis and development ability - and for many projects there's a lot of surrounding domain knowledge (and/or history) required to post more valuable comments.
Also worth noting: high-frequency, low-analysis comments along the lines of "it's broken" can still be useful - they're often an indicator that a bug has been introduced, and can be the equivalent of comment storms on Twitter asking whether a service is down after a website/API has an outage.
Coming back to the problem: it's difficult to scale the ability of small groups of maintainers to respond to large volumes of comments - as the article alludes to, it can become a kind of "time denial of service" attack. I'd guess that problem is most pronounced for developer-and-end-user-facing projects (web frameworks, for example).
One solution could be tools that help maintainers cluster and categorize comments -- customer support tools are often designed to do this.
Another idea is whether it'd be possible to challenge the commentor gently to check whether they've provided all the relevant information. This could theoretically be conversational (human or automated) -- and that's similar to tech support in traditional IT.
Finally, a structural solution is to attempt to choose software architectures that distribute the support load and allow clusters of maintainers and developers to develop expertise in particular areas. This is, to a large extent, naturally the way that open source evolves. If one project becomes too heavyweight, then frequently we'll see smaller libraries emerge that provide the core functionality elements with a smaller code surface. If development slows unacceptably or moves in problematic directions, then motivated actors generally step in to fork or create an alternative.
In summary: I think that these ticket entitlement issues have likely existed in closed environments for a long time, and there are patterns and tools for dealing with them that may be valuable. Also it's a software-and-organizational architecture issue (in an evolutionary environment with no central authority).