I was hoping that Tom was going to 'loosen' SemVer a bit, but instead he's doubling down, and that's to our detriment. Following SemVer as stated--any "breaking change" to the API must be released with a major version bump--communicates less than an ad hoc versioning system. Because some "breaking changes" may be in areas of the API that is used by few people (and sometimes literally no one), but a major version bump communicates "breaking change" to everyone. Or, every release is a major version bump, and so contains no information at all. When this happens several times a year, users just don't have the bandwidth to sincerely investigate how breaking the changes are going to be for their own use-cases. So either they delay upgrading out of fear, or they YOLO blindly upgrade to the latest, but either way, SemVer has contributed to a culture of "who the hell even knows what's going on in their computer (or with their project's dependencies) anymore".
I think a better solution would be a less-strict SemVer: the notion of "breaking changes" that require a major bump would be tempered by the number of users affected by the change. If it's rarely used feature or API edge case, then we can risk a minor bump. If we've changed a commonly used API that will break some large % of user experiences, or a large number of uncommonly-used APIs that might in aggregate affect a large % of users, then we do a major bump. Of course this require some intuition about usage, and a very human judgment call, but that's all versions ever have been: a toplevel way for developers to communicate to users the degree of change and risk of upgrading.