Versioning is a complex and hotly debated topic. Generally you want to increment the first number if you have a really big upgrade that introduces and/or breaks many functions.
In the past the first number has been incremented from 6 to 7 with the introduction of anonymous function (and an overhaul of the graphics and the JIT?). Version 8.0 (R2012b) introduced a completely new UI with a toolstrip. Interestingly the introduction of HG2 (a complete overhaul of how graphic objects behave) didn't merit an increment, but simply appeared in 8.4. If I recall correctly I have seen some suggestions that you could enable HG2 prior to that (for beta testing purposes), but I have never experimented with that.
The next increment came with R2016a, which introduced live scripts and the ability to pause an execution. It is not hard to see how those two changes would require many changes, ultimately leading to incrementing the main version number.
There is a big gap between R14 and R2012b. This has led to R2012a being version 7.14, so the issue you are pointing out has been bigger.
The main message is this: don't treat the version number as a decimal number. You need to think of it as major.minor.bugfix.build (I don't know if Mathworks is actually using this system; you could compare the version numbers between the release version and an updated version).
To answer the question in your title: apparently Mathworks didn't think the changes were so large that incrementing the main version number would be appropriate.
If you really want steadily increasing numbers you can either use something like my ifversion function (or verLessThan), or use code like this: [10,1]*(sscanf(regexp(version,'R\d{4}[ab]','match','once'),'R%d%c')-[0;97])
