When using semantic versioning, there still is the decision to be made which changes are considered "major", and which are "minor". There are various reasons to bump the version number - or to not bump it.
Systems with backward compatibility promises might end up bumping up the major version number with most updates, just because there is a backward compatibility break in some more or less esoteric corner case. The same systems might up sticking to 1.x.y almost indefinately, because a lot of effort is put into backward compatibility, trying to never break any dependant system. Both approaches to version numbering could be considered "conservative", but both could also be a sign of a deep underlying problem.
Other times, you actually have a release schedule (think of quarterly update CDs sent out to customers) where it makes sense to change the major version number, so that instead of "Version 3.4 / Oct 16" it just says "Version 11.0". Nowadays, more and more software is released in short intervals, making release schedules less of a reason to stick to a specific versioning scheme. I've seen this in big warehouse systems that allow internal IT only one day of downtime a quarter (usually a sunday). This day is the deployment day and is marked with a new major version every time.
Some programs have external dependancies that are of uttermost importance, because the user will have to update both at the same time. If you have a Word-addon that only works with Word 2010 and another one for Word 2013, you may wish to synchronise your major version numbers to that of MS-Word. Here, major numbers are so important, because some of your users will be "behind" your normal update schedule, since they haven't updated to the most current version of Word (or whatever else you're relying upon: SAP, Dynamics, etc).
Sometimes, other external factors dictate version numbers. If you have fiscal software, there might be annual updates corresponding to tax law (which tends to come into effect on Jan 1st). Such systems will have major versions changing exactly once a year - not because that is the update schedule, but because that is of other importance to the customer: If you do your 2016 taxes, you better have program that is updated to 2016 tax law.
In the end, version numbers are dependant on so many factors - often specific to one domain - that the number alone does not tell you anything about the state of your codebase. It is a much better approach to look at when, why and how deployments happen - and how smoothly that goes. If you can roll out a major update to 10.000 customers and have a couple of phone calls - you're probably fine. If you roll out a minor patch to 10 customers and have to work overtime because of that, something is probably wrong.
