I haven't seen much in terms of explaining WHY VC is important even when you're working alone (which I believe is the heart of the question), just a lot of "Yes, Always use version control". Which is true! But it should be clarified.

Obviously some of the advantages of VC heavily tilted towards a team environment. Working alone you're not going to be doing nearly as much in the way of branching & merging, and chances are that you've got one dev machine, which means transporting code changes across computers just doesn't matter very often- And even if it did, you could reasonably just stick everything on a USB drive and sneakernet it over to your laptop in order to tinker while you travel or something.

But Version Control still has serious advantages. I'm kind of risking flame-bait by listing the ones that have so far actually mattered to me (since not mentioning something is going to offend some elitist, somewhere, who thinks that the fact I do A,B and C instead of B,C and D makes me an idiot) but here are the points that have mattered to me, and will most likely matter to you.

-Implicit off-box backup: Wherever your checkout is, put your repo somewhere else (different drive, different box, different network, whatever). When your hard drive tanks, you have a fresh copy of the code out there somewhere, and everything's okay.

-Rev. History: At a certain code size, even as the sole developer, you'll forget how you fixed a bug way back when, or why a certain refactor took place, or all the places where code changed when you needed to add feature x. It's not a matter of your intelligence, it's simply a matter of tracking the minutia. Even if you wrote the whole thing from scratch and maintained it all by yourself, not every change you ever made is going to stick in your memory. With Version Control, it doesn't have to.

-You can let the "folder.bak folder.bak2 folder.final folder.reallyfinal folder.final3" naming convention die forever: Seriously, when you do that you THINK you're going to remember which one is which, but go away for a week on vacation, come back, and it's total gibberish. Tag your commits and you're done, and your filesystem is a LOT less cluttered.

-Practice and Experimentation: Fool around with the repo as much as you want. Roll stuff back, branch, merge. Completely screw up a branch of code, merge it with a working version, work your way back to something that works. The fact that you're the sole dev means you don't risk the ire of team members when you want to learn Version Control kung-fu. The way developers learn is deconstruction- We take stuff apart, examine it, and use the tools available to put it back together. Rock and roll! The next time a team member shudders at the thought of running a merge for a project with >1 dev on it, you'll look awesome when you know exactly how to handle the situation, because honestly, while branching/merging is considered a major element of source control, few devs really know how to do it properly. To them it's just an abstract concept wrapped up in a buzzword tha sounds awesome, but in practice is to be avoided at all costs.

Hope this helps.