Sigh... Do learn to read, would you? _I_ never advocated trying to save (3) from their stupidity; Eric has and IMNSHO he's delusional. I have seen turds of that variety (in the "look what a power-luser has put in crontab" kind of post-mortems), but said turds had been FUBAR anyway.
The whole point is that checks must make sense. Slapping a heuristic that happens to trigger on what one wants to prohibit as well as on a bunch of other use cases and saying "oh, it prohibits more, so it's better by definition" is *not* a good way to get better security.
It's not a matter of overhead; it's not that large to start with. The real issue here is that you generally want the behaviour of system to make sense and its mental model to be understandable. I.e. the rationale for restrictions should be simple and specific; the more arbitrary they are, the worse.
Again, I have no serious objections against that kind of restrictions. open()/creat() and probably truncate() on the final step of pathname resolution. But it really needs to be done right.
BTW, as for the hardlinks... mount --bind /tmp /tmp is much better mitigation for that; you get an equivalent of /tmp being on a separate fs as far as link()/rename() prevention counts without changing the disk layout, etc. Race-free and with less overhead as well. Can be done at the same time when initscripts mount /proc et.al., transparently for all userland. Any software that breaks because of inability to rename() or link() between /tmp and root filesystem is (a) broken on a lot of boxen already and (b) very suspicious, while we are at it.