Question: Right now, I use visual svn on my server, and have ankhsvn/tortoise on my personal machine. It works fine enough, and I don't have to change, but if I can see some benefits of using a DVCS, then I might give it a go.

However, if there's no point or difference using it without other people, then I won't bother. 

So again, I ask, are there any benefits to using a DVCS when you're the only developer?

Answer: 
Yes! I think the biggest benefit is the better branching + merging support offered by many DVCSes. Branching and merging is kind of a pain in the ass in SVN; it's annoying enough that it's not worth the time to create small, short-lived branches for quick feature additions, bug fixes, or experimentation, but merging is also annoying enough that it's a pain to create long-lived branches as well. On the other hand, branching and merging is a breeze in Git, so much so that I create a (local) branch for nearly every bug fix or feature I work on.

I think the tools offered by Git for visualizing repos, grepping logs, etc., are a lot better than in SVN, too (although that's more a Git thing than specific to a DVCS).

A DVCS also doesn't require a central server; when using SVN as a developer, you have to create a local repo to push into, which isn't a requirement with Git, since every repo contains the full history. As a corollary, archiving a repo is just a matter of zipping up your project -- there's no "central database" to back up.

I started using Git nearly four years ago, after using SVN for a while, and I haven't looked back.
I use a DVCS a lot for my own personal stuff. (I'm one of those guys that [at $HOME in git](http://joey.kitenet.net/svnhome/).) There are several advantages:

* It makes replication between my laptop and desktop and lab computers *really* easy. Though this was true of SVN also...
* I can commit on the laptop even when I don't have internet access.
* Backups are as simple as a `git pull`.
* I can use `git citool` to break up lots of changes into logically-sized commits, even if I've made lots of unrelated changes before deciding to commit. I'm not aware of a tool to do this in Subversion.
* When I have to patch an open source project, it's easier to keep things organized by making a new git repository in the project directory than it is to make a second copy of whatever source tree I'm patching. (You can’t do this easily with Subversion because you need a separate repository somewhere else on your hard disk entirely.)
* I use the easy branching features to check in revisions I get from other people. For example, when I edit a conference paper with my advisor, even though he doesn't have access to the repository, I can send him a copy of the paper, and check in his revisions in a branch based off the version that I sent him, and then use `git merge` to merge his revisions with anything I've done in the mean time.

Git got me used to thinking about all of my changes in logical chunks, a lot more than Subversion ever did.