It's actually the thing you use instead of O_SYNC because it's expected to deliver better synchronous performance, tantamount to using fdatasync() vs. fsync().
A broken fdatasync() (or O_DSYNC) is kind of a serious problem.
I think that for macOS so far, the focus has been on ordering guarantees, i.e. write barriers to reset the disk back to some atomic point in time after a crash.
However, for distributed databases like TigerBeetle, we also need durability guarantees, i.e. be able to know that the disk has the data down cold, that the disk won't “forget” data that the node has underwritten and ACK'ed externally.