I can see a trade off here: effectively we're talking about different strategies for reducing the amount of noise.
With GitHub you reduce the noise because people who know how to use Google will find the relevant issue and either contribute to it or find an answer to their question. OTOH everyone else submits issues with no regard to what's already in the issues list.
With Discord you do it by putting an auth wall in the way, which reduces the overall number of people reporting issues and asking for help but, OTOH, everybody who signs up has to ask for help.
Even with that, I'd still prefer GitHub issues, but I can see why some owners would get annoyed with it.
I think sometimes people want communities rather than projects so they go the whole hog with realtime chat: IRC, slack, gitter, discord, etc.
Personally I find it a barrier to entry since I have no desire to sit around in a chat room where support is typically blended with shitposting, infighting and drama.
At least perhaps consider a middle ground like Discourse or phpBB.
That makes sense, and I think I probably come down in a similar position to you. I'd say it can be great for a project to have a community, but I don't think I'd conflate managing and supporting that project, with interacting with the community in quite that way.
Years ago I looked after a product that the company I'd worked for had acquired which had hundreds of thousands of users. Originally the only avenue for support for that product had been email and that was a problem because we were overrun with emails asking very similar questions, and nobody was responding to them (or had time to). So I started creating blog posts to answer these questions, every time I encountered a new question, and sending them in very short responses to emails. I.e., effectively I created a knowledgebase, but I used a blog because it was the most convenient, and least bureaucratic way of achieving the solution: I won't say it wasn't politically charged, because it definitely pissed a couple of people off, but it got the job done and avoided a zero outcome scenario because I didn't get blocked by these people (one in particular). Sending out these knowledgebase posts started to reduce the support burden because now, of course, we had a search-engine indexed body of content that people could find online.
The point being if you're a small team and you want to minimise the amount of work you need to do to support your project, unless you have a very small and niche community, you're much better off creating resources that are openly available, than in some sort of walled garden, especially if the walled garden means you have to repeat yourself a lot.
