I often wonder if the projects my team works on ends up that way. We A/B test a lot of changes and often find that it makes absolutely no difference in conversion. In the end we often don't change things that seem to be "obvious" improvements for fear that we'll just frustrate our customers by changing things in ways they don't care about.
UI design is hard :-)
Github's issue tracker is also very half baked, every real project has to has a Trac instance or so somewhere else.
But _it has critical mass_, and pull requests and the way commenting them and testing them etc works is really awesome, and it'll be hard for a new competitor to get people to move.
I have been thinking, though, that I don't like the workflow associated with commenting out of band. I would really prefer that people comment by making a branch and modifying my PR (either with code comments or just fixing the problems directly). If I knew how to do that efficiently, I probably would have almost no attachment left to GH.
Granted, there are a lot of warts and confusing navigation and organization, but in many ways this is a function of trying to serve so many disparate use cases. Certainly it could be a lot better, but it's far from easy—certainly not the type of thing you could just throw a UX designer at, but something where you need a UX visionary who also happens to be a developer with deep understanding and practice using git.
I agree with you that Issues is terrible though. I tried to use it for my team, but the show-stopper was that you can't move issues between repos, and so there is no way to stay organized across a non-monolith architecture where you need to take issues in based on front-facing products and not just code-level concerns. If it wasn't for that, we probably would have tried to suffer through it just for the integration benefits.