(I'm not a security person)
Read svckr's comment below and link #1 - what I was saying here before my edit was wrong. :D
1: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... (2nd post)
When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses.
The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit. With a tag, you'll just update the tags and the rest of the branch remains unchanged.
I hope, together with the thread you posted, this at least makes some sense.
Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.
(thank you, kind expert)
I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.