The article mentions in passing that it is safer to write changes to a new file and rename it than to overwrite a file in place. This in itself is actually an example of a bad design - similar to the recent fiasco over app designers being told to fsync their changes.
The ideal design would be for applications to tell the OS what they want to do, and for the OS to do it. In this case, the application WANTS to atomically modify the contents of a file, but since the OS provides no capability for atomic updates instead the application PRETENDS that it wants to create a new file, rename it, and unlink the old one.
The solution in this case is transaction support within the filesystem. Then if you have a copy-on-write filesystem or whatever you're not forcing the system to rewrite the entire contents of a file to change a few bytes in the middle safely.