If you look at the POSIX standard, it doesn't actually imply that fsync() before rename() matters at all. There's not really even a suggestion that the stable storage representation of the directory gets atomic changes, or, in particular, that it won't go through a state where the directory would appear with something different from either the original inode or the replacement inode. fsync() is important if you want to be sure that there is an inode that contains your new data, but there's no particular reason (aside from filesystem internals) to think that your filename will point to it.
The standards don't talk about system crashes, so anything that applications do in order to cope with system crashes is inherently ritual. (The rename() trick, ignoring fsync(), is defined to be helpful against application crashes and poorly-timed SIGKILL.)