That makes a lot of sense - however, you asked me, where to implement it from a user's point of view. And I still believe that this would be the correct place. If the Branches view has performance issues in large project, what's different with the new "All branches + Tags" view? Maybe you can rewrite the new view to present branches in the same structured way, as it was in the "Branches view" without introducing whatever caused the performance issues? Or refactor the branches view to fix the performance issues? I don't know all the details, but from git side, I don't see the bottleneck when running `git branch --list` and `git branch --list -r` to get all local and remote branches.

Currently it seems just messy and for large projects, I believe it's even messier if you have hundreds of branches in a flat list.

Sure - I mean you already have a well-structured and good solution for this problem in the file-oriented view that is everything I need, where I need it (except the stashes, that feel a bit off here and are fine with me if they move somewhere else):

so I would recommend to just (re-)use this instead of this flat, unorganized view:

You can call it "All branches + Tags" which would still be correct. For me it's not clear what's the benefit of this new view anyway. 

Hope this helps