Well, the usage so far has been backwards compatible AFAIK. You start out unversioned, and if a field is added, an nVersion check is also added. If no nVersion check exists, that data structure is unchanged.
(minor nit pick: nVersion already exists, and is set to 1, but that's a trivial point)
You're assuming the software will be updated at the same time as the data structure. That is a really bad assumption to make.
Think it through. Version 1 clients don't check version numbers. Now, what happens when a version 1 client tries to read version 2 data? It will assume that the data is version 1, so it will just blindly go ahead and try to read the data. That is a sure recipe for disaster down the road. Defensive coding 101 - validate everything.
I have learned through bitter experience that you check version numbers starting at version 1, not at version 2. Unless, that is, you have complete control over the software distribution and the data you're trying to work with - which we do not.
The current system seems straightforward and is backwards compatible, so why add superfluous checks?
And, as I said, trying to maintain backwards compatibility is a fool's errand. You might be able to carry it on for a short period, but sooner or later you're going to have to put in some really complicated, hard-to-maintain and error prone code in the name of "backwards compatibility."