Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results.
This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)
That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.
I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite)
/ # stat /dev/null
File: /dev/null
Size: 0 Blocks: 0 IO Block: 4096 character special file
...
/ # sed -i 's/foo/bar/' /dev/null
/ # stat /dev/null
File: /dev/null
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
...
It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.
This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)