There is a key difference between an issue tracker and the repository itself:
The issue tracker isn't distributed with the repository
When one downloads the library or does a
git clone https://github.com/jsmith/acme, the license that the library and code is distributed under needs to be there. Consider the situation where someone had their code on Google Code, or Source Forge with the license in the issue tracker over there and then migrated the project to github... and there's no hint of a license file any more.
Specifically with GitHub and its culture of forking, one should also look at what one sees when downloading or cloning from a fork. There isn't even a hint of an issue containing the license in the forked code. For that matter, the fork might have enabled its own issues on there and claiming a WTFPL license on it (anyone downloading from the fork and going to
https://github.com/sjane/acme/issues/97 hinted at by someone as containing the license in it could see something completely different than the MIT).
The license needs to be distributed with the library and source files. Otherwise there is no license on them and it makes the legal department rather twitchy.
Furthermore, issue trackers aren't tied to a revision. Consider if jsmith later decides to switch from MIT to GPL (as the only author, perfectly acceptable). And now... what's the license? There's one issue here that says its MIT and another one there that says its GPL. If I clone from revision 1, what license is it under? What about if I clone from revision 2?
The only way to resolve this is if the license is part of the distribution itself. Posting it in an issue tracker doesn't actually identify the license that a given revision is under. Nor does posting it in an issue tracker allow me to redistribute the code under the license I (might have) received it under when that issue tracker is gone.