Version control and the associated tool addresses the following (at least)
- Backups (for when you lost or deleted something)
- History of changes (for when you made a mistake and need to go back)
- Collaborative working (sharing and merging)
- Reviewing
- Bug fixing and development on different branches
As I've written these, I think they're roughly in order of being less obvious or harder to grasp. Everyone is familiar with the need to keep a backup of an essay (we hope) but the idea of going back to look at how something was written at the start of last week's lesson is rather more unique to writing code.
The most obvious prerequisite would be to get to the stage where rather than starting to write a program from scratch, it's better to take something old and re-purpose it. This is roughly the same point where you start to care about loosing something (to start with, code gets better if you write it, throw away and start from scratch again).
Although it's slightly tangential, I would also say it is better to talk about review and collaboration before introducing version control.
I don't think it's as important to be in a position (from the start) to need to explain about switching between different branches, cherry picking, etc. A lot of the really useful ideas come from the head, logs and diffs.