There are very few cases in practice where it's needed. The bigger issue is deciding what consistency semantics you _do_ want to have once you decide that strong isn't necessary. Every decision exposes another corner case where someone's application breaks.

Imagine two processes appending rows to a csv file. If writes were non-atomic, they might insert partial rows, or overwrite each other.

the append case is actually different, it requires serializing the end of file pointer.

in the write atomicity case we're asking the file system to order all the writes, and make sure the resulting file shows each of them being completed in their entirety before the next is applied, without any interleaving even if they refer to the same byte offsets in the file

Aren't these atomic writes only a reflection of the fact that data is written out as blocks?

well, yeah, it wouldn't otherwise be necessary for the writes to be fully serialized (because blocks and the cache traditionally, but really anything)

edit: its also worth noting that even in the traditional implementation since the block interface doesn't provide atomicity on faults this is kinda probabilistic anyways