There's a critical point here I think needs to be stressed.
Bzr is primarily used as a tool to interact with launchpad.net. It's never really garnered significant adoption as a standalone tool. Yes some people do use it outside of launchpad, I'm not saying there is zero interest in bzr sans launchpad integration, just that i don't see critical mass in bzr community if launchpad integration were lost.
Because of the intimately tied nature with a Canonical controlled service (launchpad) there is less overall incentive for an external to try to create and lead a competing fork for fear of creating an incompatibility with the launchpad.net service requirements. It's forkable, the license on the code assures that is a possible future, but I doubt anyone is going to ever seriously do it.
It's a deep tangle.
I've yet to hear of someone attempting to take the launchpad.net sources and spinning in an alternative site. If someone did that, forked the launchpad.net codebase and spun up a implementation outside of Canonical's control, then a fork of bzr would be an obvious part of that much more involved effort. In for a penny in for a pound.
The irony of course being that the deep integration with launchpad is probably the only reason keeping bzr alive as a project at all at this point. If Canonical threw away launchpad entirely and started from scratch today... I'd wager they'd pick up git as part of the scaffolding. bzr is just a long lived piece of technical debt at this point for the launchpad team inside Canonical.