Pros for hard links and when they are better:

• if you need two names for the same file, but one of them might be deleted or renamed
• If the purpose of the linking is to save space and/or reduce redundant files, and the relationship between the link and the target is not important

Cons for hard links:

• There is no source/target relationship between hard links. All hard links are identical. The inode doesn't store the filenames that hard link to it, so the only way to find other hardlinks to the same file is to search the entire filesystem.
• Some filesystems put a limit on how many hardlinks can reference the same file, but this practically is never an issue.
• The inode holds the file permissions, so you can't have two hard links to the same file with different permissions or ownership. In some cases, this can cause security issues with users linking files into directories the owner cant delete them from. (Some systems block this.)

When symbolic links are better (or the only option):

• if you want to link to a file on another filesystem
• if you want to link to a directory
• if the relationship between the two files is more important than accessing the data if the target is deleted or renamed
• if the information you want to store and view is not the content, but the name of the target in the link
• if the content of the file needs to change based on situation; examples:
  • a symbolic link to a file in /etc on a network shared filesystem, where the target is local and the symbolic link is not
  • a relative link to a file in another directory, where the current directory might be moved and you want to keep the relationship not the content (where there might be a parallel structure in the new location)
• Symlinks can implement a primitive version of copy on write, where a second user can make a shadow directory tree of symlinks to another user's files, and then delete the symlink and replace it with a copy of the file before editing it (or have the editor do this automatically).

Cons of symlinks:

• Symbolic links can be fragile; if the target of the symlink is moved or renamed, the link is broken.
• Symlinks to directories can create a maze of twisty paths, making it confusing what the real path is.
• Symlinks to directories can cause loops, and naïve applications that don't check for them and traverse them blindly (like vscode) can get into infinite loops.
• Symlinks are notorious for causing security issues, where an application can check a symlink's permissions and then another program can replace the symlink in a race before the first application uses it. (There are many mitigations for this.)

Note that use of hardlinks and symlinks is very situational, and that a particular feature can be a pro in one situation and a con in another.

Pros for hard links and when they are better:

• if you need two names for the same file, but one of them might be deleted or renamed
• If the purpose of the linking is to save space and/or reduce redundant files, and the relationship between the link and the target is not important

Cons for hard links:

• There is no source/target relationship between hard links. All hard links are identical. The inode doesn't store the filenames that hard link to it, so the only way to find other hardlinks to the same file is to search the entire filesystem.
• Some filesystems put a limit on how many hardlinks can reference the same file, but this practically is never an issue.
• The inode holds the file permissions, so you can't have two hard links to the same file with different permissions or ownership. In some cases, this can cause security issues with users linking files into directories the owner cant delete them from. (Some systems block this.)

When symbolic links are better (or the only option):

• if you want to link to a file on another filesystem
• if you want to link to a directory
• if the relationship between the two files is more important than accessing the data if the target is deleted or renamed
• if the information you want to store and view is not the content, but the name of the target in the link
• if the content of the file needs to change based on situation; examples:
  • a symbolic link to a file in /etc on a network shared filesystem, where the target is local and the symbolic link is not
  • a relative link to a file in another directory, where the current directory might be moved and you want to keep the relationship not the content (where there might be a parallel structure in the new location)
• Symlinks can implement a primitive version of copy on write, where a second user can make a shadow directory tree of symlinks to another user's files, and then delete the symlink and replace it with a copy of the file before editing it (or have the editor do this automatically).

Cons of symlinks:

• Symbolic links can be fragile; if the target of the symlink is moved or renamed, the link is broken.
• Symlinks to directories (or symlinks!) can create a maze of twisty paths, making it confusing what the real path is. (All hardlinks are the real path.)
• Symlinks to directories can cause loops, and naïve applications that don't check for them and traverse them blindly (like vscode) can get into infinite loops.
• Symlinks are notorious for causing security issues, where an application can check a symlink's permissions and then another program can replace the symlink in a race before the first application uses it. (There are many mitigations for this.)

Note that use of hardlinks and symlinks is very situational, and that a particular feature can be a pro in one situation and a con in another.