Trying to explain why git is better than svn is like trying to explain why svn is better than cvs. To someone who has never used it, they simply can't imagine anything better. I've actually been in the position of advocating svn over cvs and been shot down with arguments much the same as you are making now (that cvs has almost everything svn has).
There are a myriad of git commands that do all sorts of useful stuff. mergetool, cherry, rebase -i (interactive), add -i (interactive hunk based add), gitk (for visualization), colored diffs, a history aware grep, bisect (for narrowing down a patch that broke a feature), and dozens of others.
To directly address your comment, changing history may sound like a convenience, but it makes things a lot easier. Some person's patch breaks the website? You may find that the entire change is self contained in one or a small series of contiguous patches, making it super simple to revert. In subversion I've had to track down and revert 15 separate disparate commits over a series of weeks to bring a piece of software back into line. Another benefit is that as you are working, you can add your current work without committing and diff that version against any new changes you make. This makes it extremely easy to develop because you can keep track of just what you've done in say the last 15 minutes, as opposed to the entire day. It is great to be able to go back and review what you've done and tidy it up a bit.
Everything on the client side that svn does, git does better. I want to list more actual use cases, but this post keeps getting too long. So Instead I'm going to encourage you to experiment with git svn at work, or on one of your personal projects. You'll mess up a couple times at first, but the productivity you gain after a few days will be well worth it. I've converted a couple people at work, and they seem happy. Personally my productivity has doubled or even tripled, although I cannot guarantee that will be the case for everyone.