The reason `fsync` exists in Unix is for applications to avoid calling it.
Unix could have made filesystems sync automatically, but that would have a high cost, because it would end up doing a of needless work for temporary and intermediate data. Instead of having the filesystem abstraction convey the intent of data, Unix bubbles up the responsibility to call `fsync` to higher-level application code.
In this design, tools like `sed` aren't meant to call `fsync`. They operate near the level of the filesystem abstraction and don't have the information they'd need to decide when not to call it. A script might invoke `sed` a thousand times and then do a single `sync` at the end, avoiding much needless cost while still achieving the desired end result.
In contrast, `vim` does call `fsync`. The thing that makes `vim` different is that it knows a tiny bit about where it sits with respect to a human being's intent.
So the decision to use `fsync` isn't about not letting errors pass silently. It's about whether the code you're writing has a bigger-picture understanding of the data it's processing.
