The existing implementation is mainly for detecting read-only file system (mkdir fails with EROFS) and unmounted storage (fails with EPERM).
We have seen cases where written data is lost after closing because delayed block allocation failed in kernel. Since this failure is asynchronous to the file write/close, no user process received an error. I think enabling syncOnClose will make such writes to fail with EIO. The write-sync test will more likely detect this kind of conditions, so I think this approach has a merit.
Another common disk failure mode involves read error. Writes go through fine, but reading back can cause an unrecoverable error/hang. Unless the affected sector is used for file system metadata, no action at file system-level will be taken. This is kind of being dealt with by adding the affected block to the volume scanner queue. The write-sync check will still catch many bad disks.
Any particular reason why it retries on FNFE? When do you think that will happen?