Because I don't want my default view to be "triage." If GitHub allowed default issue views (and reflected that in the issue count in the tabs as well), then maybe. But currently, it doesn't work. I've tried it at large project scale across many (multiple projects with more than 20K stars and millions of downloads).

Compared to that, this system has been a huge success. It has its own problems, but it's directionally better.

For one, it might require several rounds of back and forth before its ready to receive the tag, but now the details are spread across several comments instead of neatly at the top

An non-issue raised as an issue can never be closed, because the person who reported it will just open another one saying "Why did you close my issue without fixing it?" If that user is also raising valid, useful issues then you don't want to just ban them. Consequently your issues list will become unmanageable.

that solution is not trivial because it requires permission for anyone to comment on issues, which invites irrelevant or unhelpful comments or even complaints. the separation allows issues to be limited to developers only, those who actually work to fix the issues.

technically, messages are messages. this approach no more than grouping messages into different forums. it could also all be under discussion with a sub forum for issues, one for features, one for other topics, etc, and then there would need to be a permission system for each sub forum.

so all this does is to create two spheres of access for users and developers. and that's the point.

in the end it's really a matter of taste and preference.

How is it not trivially solved by a discussion section? Why is your solution better for someone else's work flow? Why do you feel like you get to impose your way of doing work on an open source project?