(This is largely based on A Git Horror Story: Repository Integrity With Signed Commits—a very good read, and more information than I could put into an answer.)
There are a number of ways in which a git repository can be compromised (this isn't a security flaw, just a fact of life—one should not avoid using git because of this). For example, someone may have pushed to your repository claiming to be you. Or for that matter, someone could have pushed to someone else's repository claiming to be you (someone could push to their own repository claiming to be you too). This is just part of life in a DVCS.
Just as an example:
$ git config --global user.name 'Madara Uchiha'
$ git config --global user.email firstname.lastname@example.org
There, I've changed my git configuration to pretend I'm you. And now I can commit away and let those commits somehow make their into the production build, and it looks like you've done it.
With signing of the commits (and tags), one can prove that certain commits and tags were from you (and things that aren't signed shouldn't have made it into the production build). That's really the key to it all—by signing commits you've said it's your work.
The "your work" aspect is particularly important in the linux kernel (and thus git) that is occasionally hit with copyright lawsuits. By signing commits you say that you have the right to the software—it tracks the origin. It may be that you've got no access to the source that is being claimed as copyright and the claim is groundless. It may be that the company forgot that you were working for them a few years ago and under their direction added material to the kernel, or whatever.
There is some debate as to if every commit should be signed. From GPG signing for git commit? (back in '09), Linus wrote:
Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need one signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.
Much more about the thoughts on signing in git can be read there too.
That said, it made its way into git anyways.
There seems to be a majority consensus that signing commits is unnecessary, but signing tags is very good. That blog post linked at the top suggests that one should sign everything anyways. As I said, there's some debate about if every commit is necessary or not.
The key to the "sign every commit" debate probably has to do with the workflow you use. Most people make a bunch of commits in their local repo, and then push that set. It should be sufficient to tag the final collection (assuming, that is, you make sure that all the changes are correct). If you are working in an environment where lots of single commits are moving around, the distinction between a tag and a commit becomes less… distinct—and signing commits may become more useful.