The wording here is quite subtle. Without SIO, fsync is merely a request, returning an error if one occurred. As the informative section points out, this means that the request may be ignored, which is not an error.

> If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. It is explicitly intended that a null implementation is permitted.

Compare this to e.g. the wording for write(2):

> The write() function shall attempt to write nbyte bytes from the buffer pointed to by buf to the file associated with the open file descriptor, fildes. [yadadada]

This actually specifies that an action needs to be performed. fsync(2) sans SIO is merely a request form that the OS can respond to or not. And because macOS does not define SIO, you have to go out and find out what that particular implementation is actually doing and the answer is: essentially nothing for fsync.

It makes sense that a null implementation is permitted to cover cases such as the one illustrated above where all writes are always synchronized. However, it violates the spirit of the law (so to speak) as discussed in the normative section to have a null implementation where writes are not always synchronized (i.e., cached). As another commenter noted, the wording was not intended to give the implementor a get-out-of-jail-free card ("it was merely a request; I didn't actually have to even try to fulfill it").

There’s also the very likely possibility that the storage is lying to the OS, that the data that was accepted and which is in the buffer has been written somewhere durable while it’s actually waiting for an erase to finish or a head to get wherever it needs to be. There are disk controllers with batteries precisely for those situations.

And, if cheating will give better numbers on benchmarks, I’m willing to bet money most manufacturers will cheat.