While it is pretty cool, using such tool increases general lock-in to GitHub, in terms of both habits and potential use of it for automation of processes.
I wish there was an open standard for operations that hub allows to do and all major Git forges [1], including open source ones, such as Gogs/Gitea and GitLab, supported it. In that case having a command-line tool that, like Git itself, is not tied to a particular vendor, but allows to do what hub does, could have been indispensable.
You can do a lot of what it does with plain old aliases and really should if you work with multiple forges.
You're also only talking about a single git use case which not everyone follows, even within a single forge.
Something tackling the problem from the other end is phabricator which integrates each VCS into the same forge platform. Well, mostly (badly), it's kind of a total mess with specific things you need to work around for each.
I can see the same thing happening to anything trying it from the forge end.
Just because gitlab has pull requests does not mean that GitHub born idea is the best or will even stay.
How would you marry up Gerrit to GitHub (you can't).
What you're asking for only really works for something following gitflow, which would be kind of stupid to base a standard on because it's broken by design and doesn't scale. But you would have to because otherwise GitHub won't use it.
I wish there was an open standard for operations that hub allows to do and all major Git forges [1], including open source ones, such as Gogs/Gitea and GitLab, supported it. In that case having a command-line tool that, like Git itself, is not tied to a particular vendor, but allows to do what hub does, could have been indispensable.
[1] https://en.wikipedia.org/wiki/Forge_(software)