Why do hard links exist?
The main advantage of hard links is that, compared to soft links, there is no size or speed penalty. Soft links are an extra layer of indirection on top of normal file access; the kernel has to dereference the link when you open the file, and this takes a small amount of time. The link also takes a small amount of space on the disk, to hold the text of the link. These penalties do not exist with hard links because they are built into the very structure of the filesystem.
The best way I know of to see this is:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
The -i option to ls makes it give you the inode number of the file. On the system where I prepared the example above, I happened to be in a directory with inode number 1069765, but the specific value doesn't matter. It's just a unique value that identifies a particular file/directory.
What this says is that when we go into a subdirectory and look at a different filesystem entry called .., it has the same inode number we got before. This isn't happening because the shell is interpreting .. for you, as happens with MS-DOS and Windows. On Unix filesystems .. is a real directory entry; it is a hard link pointing back to the previous directory.
Hard links are the tendons that tie the filesystem's directories together. Once upon a time, Unix didn't have hard links. They were added to turn Unix's original flat file system into a hierarchical filesystem.
(For more on this, see Why does '/' have an '..' entry?.)
It is also somewhat common on Unix systems for several different commands to be implemented by the same executable. It doesn't seem to be the case on Linux any more, but on systems I used in the past, cp, mv and rm were all the same executable. It makes sense if you think about it: when you move a file between volumes, it is effectively a copy followed by a removal, so mv already had to implement the other two commands' functions. The executable can figure out which operation to provide because it gets passed the name it was called by.
Another example, common in embedded Linuxes, is BusyBox, a single executable that implements dozens of commands.
I should point out that on most filesystems, users aren't allowed to make hard links to directories. The . and .. entries are automatically managed by the filesystem code, which is typically part of the kernel. The restriction exists because it is possible to cause serious filesystem problems if you aren't careful with how you create and use directory hard links. This is one of many reasons soft links exist; they don't carry the same risk.
One usage of hardlinks which is extremely useful is in incremental backups combined with rsync. It saves lot of space and makes the restoration procedure really easy. I use that approach for backup in my servers.
Take some time to read this explanation.
If after reading that wikipedia page your question is "why would I ever use them" then you don't understand what hard links are.
A link is a directory entry that points to blocks on disk. In other words every file on your system has at least one link. When you rm a file the actual system call is unlink(). It removes the directory entry. The blocks on disk haven't changed but the link is gone, thus the file is gone from the directory listing.
You personally may not ever use hard links, but they are all over your system. For example:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
You can see that bunzip2, bzcat and bzip all use the same inode. In essence, it is one file with three names. You could have three copies of the file, but why? It would only use up disk space unnecessarily.