1) You can't always be 100% sure the code was actually written by the candidate.
2) One quality I'm looking for in particular is somebody who can work well with OTHER PEOPLE'S CODE, and that's even harder to evaluate. If I see a balance of original repos and forks, that might be some evidence, but again, how do I dig out what they contributed? Chasing down PRs would be more helpful, but that definitely is too much work for a job interview.
3) Having a busy github account could be a marker of particular life circumstances (to avoid waving the red flag of "privilege" around too much) — the candidate is not overly busy working a second job, raising young children, or giving 120% in his day job.
4) There are plenty of respectable reasons not to code in your spare time — you may have different hobbies etc. When hiring pathologists, we don't give preference to candidates who cut up bodies in their spare time. We should get out of the habit of doing so for programmers.
5) A busy github account can also be a warning sign of somebody who might be more invested in side projects (or possibly even bootstrapping a startup) than in their day job.
If you spend time doing extraneous things like documentation during a coding challenge you likely won't do well, not because documentation isn't valued but rather because you won't have time to move from the "simplest" answer to the "best" answer, let alone the "teach me something" answer. This may frustrate your interviewers because they're seeing you spend your time in a way that's not advantageous to you. They may even be more frustrated if they actually liked you as a candidate.
Tests are different because they often help you move more quickly and confidently between layers of the question as you can sanity check you revised implementation against your tests.