I don't know that developers want atomicity but not durability. I'm not quite sure if developers know what they want, most of the time. At least, there seem to be a lot of misconceptions and misuse of these things. I don't think SQL provides atomicity without durability, does it? (maybe an RDBMS specific extension, but I'm not aware of them).
It's true that posix filesystem API is not trivial to write a crash recoverable protocol on top of, when you are talking about multiple files and directory structure, but it's not rocket science. I think a lot of userspace developers believe that it is terribly difficult and non-performant to implement in their apps, but it would somehow become free of complexity and cost if implemented in the kernel.
Not only would it not be free, but it would add a lot of complexity and divergence (between fses, other OSes) to a layer that is currently quite simple and used by all sorts of apps that do not need such semantics.
I'm not saying it would be a useless feature. But I have not seen anywhere somebody show code and numbers showing that it is compelling, over alternatives. Alternatives include implementing your own atomicity/cleanup protocol on the posix API (which really isn't too hard, and can absolutely include asynchronous writeback until durability is required), or using sqlite or bdb or something to either store all your data or at least store a log of the state of your file/directory structure. And mind you, the alternatives are very well tested and will work on all OSes.