Why not just not support hard links?

He's using a rather expansive definition of "hard link." Usually, "hard link" refers only to a reference to a file from a directory entry. The kind of reference you get when you open a file isn't called a hard link. (It's just called a reference).

Incidentally, most of this thread is using "hard link" in a too restrictive way. When you create a file 'foo', you create one hard link to the file (from the directory entry with name 'foo'). When you ln foo bar, you create a second hard link to the file. Note that Unix files themselves do not have names -- not text ones anyway; they are traditionally named by inode number.

Directories have lots of hard links. There's the one from the parent directory, the one from '.', and all the ones from the subdirectories' '..' entries. In some modern models, '.' and '..' aren't actually considered directory entries, but you'll still see them -- for historical purposes -- in the directory's link count (e.g. from ls -l).

But you can't make an arbitrary hard link to a directory. Only the specific ones described above are allowed to exist.

I suppose what is meant is, that with symbolic links there is a distinction between the actual file and the link: removing the symbolic link leaves the file intact, while removing the file leaves you with a link pointing nowhere. This, of course, is because there are two separate inodes (the entities that keep the metadata): a symbolic link has its own inode. With hard links, you merely remove one of the references to the file (this is a number in the inode that is increased whenever a hard link is created), leaving it intact until the last link is removed. In this respect, all link names are "equal" then.

Getting back to your original question: this is also one of the reasons why you would want to use hard links. (In practice, symbolic links are almost always preferable. You should really know what you're doing when using hard links.)