@LeoDavidson covered the issue exactly.
Users think they are making a feature suggestion, when really they are asking for help on how to do something already possible. They think they are reporting a bug when really they are not understanding how things work (which, of course, may be an indication that things should work better or differently, so might be a feature suggestion too). Or they are asking for help on something that can’t be done (feature request) or should work but doesn’t (bug report).
From the user’s perspective, the real thing is “I want to do x - help me please”. Whether it is a support request, feature request, or bug report is not something they can determine.
For a typical, example, I wrote a bug report on this form recently which was promptly moved to the “ux” category. Deciding whether something is a user interface concern or a bug report is not something that even well meaning users and discern clearly.
Hence the combined category.
And as I’ve said, the category originally was called “general” to cover pretty much all questions that were not specific to some case (like plugins for example), and to fit with meta’s and Discourse’s initial prompting on how to set up a forum. After experience, we’ve moved to more complete names, but this leads to experiencing the disparity in Discourse handling.
I would say, at the end of the day, Discourse categories have two names, a slug and a title, and it seems to me self evident that both should be equally and fully supported by discourse in every place that one or other would work (maybe not the title in the URL). Certainly everywhere you can use # or category: you should be able to rightly use either slug or title (IMHO). I value consistency highly as a mitigator of complexity. But it is not my software to change, I am just an appreciative user of it.