Admittedly, npm can't control the "semantic" in semver as that will likely always be a human judgment call, but npm has a lot of general control in package versioning. Their semver recommendation [1] is pretty strong in their docs, and embedded in the default version range specifiers ^ (a previous default) implies semver major, and ~ (the current default) implies semver major.minor.
Other small ways that npm controls versioning is that it does not allow you to publish the same version number for a package [2], and `npm version` [3] is often the most common tool for incrementing version numbers, which itself provides a number of semver-focused shortcuts.
So yes, it's certainly a common expectation in npm that packages follow semver, largely due directly to npm's documentation and tools support.
> If you are operating from the premise that the maintainer is potentially compromised, why would you trust them to stick to the semantic versioning spec?
The suggestion was that in the current case the maintainer changed with no warning. One warning system that npm provides is semver major breaking changes. npm does have enough version control (for instance, the part not allowing previously submitted version numbers to be reused) that they could theoretically force all new versions submitted after a maintainer change to jump a semver major version. That would at least send a signal to the large number of developers that don't pay attention to the changelogs of minor and patch versions (and may naturally have a ^ or ~ scope in their package.json) to at least check the changelog for breaking changes. That's possibly the easiest "sufficient" fix for this problem of an otherwise unannounced maintainer change.
[1] https://docs.npmjs.com/about-semantic-versioning
[2] https://docs.npmjs.com/cli/publish.html
[3] https://docs.npmjs.com/cli/version