A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.
But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work.
It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.
It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire.
In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes.
By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.