1. We need to give clients access, and we need to give those clients fairly fine grained control - ie: This user can see the tickets, move them around, comment etc. but not close them. On some projects we have lots of people on the client side that want to be able to see the tickets, so we very much don't want to have to pay per user for client access. For many reasons, giving them GitHub access is not ideal, but the biggest reason is that GitHub's permissions model on issues is, at best, bizarre.
2. I got quite excited when I saw the words "bidirectional GitHub integration" on the home page, but then I read the description underneath and I'm having a really hard time picturing what it does. We like adding ticket numbers to commits, because that keeps a reference to the change that was made in the ticket thread on GitHub. Other devs coming in can easily read the thread and click through to see the change. Your description of the GitHub integration seems very focussed on PRs rather than tickets, and the way we work a PR is most likely to contain many, many commits, and multiple tickets.