On the other hand, there's something of an inherent metrics bias when you evaluate some candidates on one metric and others on a different one. It's very hard to calibrate those two scales, and there's a risk that you'll be tempted to do things like compare one candidate's GitHub PRs to another candidate's whiteboard code. Even if you don't make that comparison directly, you'll never dislike a GitHub-evaluated candidate for not remembering standard APIs, making off-by-one errors (if they have the luxury of a test suite), taking half an hour to understand a problem, etc. You'll never dislike a whiteboard candidate for breaking with existing style, not commenting or writing good commit messages, being a jerk to people who send in support requests as issues, not being able to respond to code review feedback, etc.

If you have unlimited headcount, you might be able to set independent baselines for both styles of evaluating candidates (although tuning them will, again, be hard), but if you're at all comparing candidates to each other, it seems likely to cause one set of candidates to have a much easier time than the other, based on which things your engineers value. And, necessarily, that means you'll be willing to hire worse candidates from one set than from the other.

Using a GitHub profile to bypass a coding challenge, FizzBuzz, or similar is fine. Using it to break ties or to allow a candidate to express "I'm actually good at my job, even though I'm bad at interviews" is probably fine, especially if there are other ways to do those. But having two different evaluation strategies is likely to be unfair both to yourselves and to the candidates.

It's nice when we have a candidate with a GH history, but I'd venture a guess that 90% of the best code written by the engineers we hired was written for some other company in private repos. I can't imagine that being too far outside the norm.