The 'ln' and 'rm' commands have worked exactly like this in every UNIX filesystem since the early 1970s. Mac OSX, BSD and Linux all inherit this original design.
By itself, a UNIX file has no name, only an inode number or inum. But you can only access it through an entry in a special "directory" file that associates a name with the inum in question; you can't specify the inum directly.
A directory is itself a file, so you must also access it through (another) directory and so on, through a series of directory names delimited by forward slashes (/) known as a "path name". A path starts in the "current working directory" of the process unless the name begins with a "/", in which case it starts with the file system root directory. E.g., if the path name contains no "/" characters, then it is expected to be an entry in the current directory.
A non-directory file can have any number of path names, known as "hard links", and it will continue to exist until all of its path names have been removed and the last process has closed the file. Then the file is actually deleted and its space marked as available for reuse. That is, you can creat() or open() a singly-linked file and then unlink() it so it no longer appears in the file system name space, but the file will continue to exist until you close it. This is useful for temporary scratch files that won't be read by any other program.
Although directories have inode numbers, most file systems disallow hard links to them; they can appear in only one other directory. (One unusual exception is the Mac OSX HFS+ file system; this lets Time Machine backups work.) You can still create "soft links" to directories (or any other file). A soft link resembles a directory entry except that it contains another path name rather than an inum.
Every UNIX file has an owner, group and access permissions. It is necessary but not sufficient that they let you open the file; you must also have at least execute permission for every directory in the pathname you use to refer to it. That's why there's no standard way to open a UNIX file by its inode number; that would bypass an important, widely used security mechanism.
But this doesn't explain why there can't be a standard way for a root (privileged) user to open a file by inode number, since permissions checking is bypassed anyway. This would be very useful for certain system management functions such as backups. To my knowledge, such mechanisms do exist, but they're all filesystem-specific; there is no general way to do it for any UNIX filesystem.