To simplify backups
Use Case 1: Relocating documents to a separate local or NFS partition
Lets say you like to update your Operating System with each new release. A typical backup approach would be to copy your home folder to a separate partition so you can copy the contents back after the install.
What I typically do is symlink the folders I want to keep backed up to the separate partition. To restore the symlinks, I just run a quick bash script to restore the links after the OS install.
I would just call it backing up your data but there's really no additional 'backup' step. The nice part is if you accidentally pull a noob move like 'rm -rf' your filesystem, rm doesn't follow symlinks so you won't lose your files.
Note: I understand that you can change the location of where /home is mounted using /etc/fstab. The reason I don't use that technique is because I only want to selectively link parts of my user files and leave any accumulated junk behind.
Use Case 2: Using a cross-platform partition (the easy way)
The added benefit to using symlinks (soft links) is that they work across different filesystems.
Some of us don't have the luxury (due to business needs) of being able to use Linux as our only OS so we jump back and fourth a lot. To extend Case 1, what I personally do is use a NTFS partition for my user files and symlink out the various config and user files that I want to pull into Linux. That keeps all of my stuff in one place.
Note: If you didn't already know, you can also create symlinks in Windows using the MKLINK command.
Imagine this. You have a Dropbox account that you use in both Linux and Windows. To keep from having to download/sync two copies of the same files it's as easy to use everything across both OSes as symlinking to the Dropbox folder on the NTFS partition from your /home folder.
Note: To auto-mount a NTFS drive (in Debian based distros, not sure about others) you'll have to add an mount point in /etc/fstab with umask=000 for write privileges.
Use Case 3: To support default and custom folder structures simultaneously
Lets say you are a webdeveloper that is in charge of working on multiple websites.
You got your testing server setup properly in:
You could try to create one massive configuration that works across all sites but that will become cumbersome to maintain over time as new sites are added. The more sites you add the more out-of-sync the permission settings will be with the production server.
What happens when you want to drop in the production server config to test for security vulnerabilities or to verify that no server-side scripting errors are being displayed to the users. Do you just add another set of exceptions for that? How confident are you that your testing configuration is the same as the one the other developers on the team are using.
Apache specifically is extremely flexible when it comes to configurations but with flexibility comes complexity; and complexity introduces risk when you're writing code for the web.
Fortunately, there's a much simpler approach. Create a bash script for each website with --testing and --production arguments. Then just configure the arguments to drop the proper symlinks into the htdocs and config folders for the specific configuration. The site could be under version control, on a separate partition, or even on a remote share. It doesn't matter, as long as the symlinks point to the right place.
This got upvoted again so I decided to add another common 2 more use cases.
Use Case 4: Making applications easily accessible via the command line
Lets say you install a new application such as Sublime Text to "/opt/Sublime Text" to give user-level access without requiring root privileges.
To make it easily accessible via the command line one common approach is to modify the $PATH variable to include the Sublime application directory. This approach may be less than ideal because $PATH has a limited length, tends to get polluted with a lot of links to shared library paths, and is more difficult to remove later.
Since /usr/bin (ie one of the main application directories) is already included in $PATH, why not piggyback on that?
The simplest approach is to create a symlink /usr/bin/ pointing to the Sublime Text executable.
sudo ln -s "/opt/Sublime Text/sublime" /usr/bin/sublime
Now launching the Sublime text editor from the command line is as simple as typing
sublime in the terminal. Sudo is only required when you create/delete the symlink because /usr/bin have user-level execute privileges by default.
Use Case 5: Seamless backup and selective sync to the cloud
Among the IT crowd one of the most commonly parroted pieces of advice is 'back up your files'. But backups are so '2000 and late'.
While there are a lot of available file synchronization services available they're not very flexible when it comes to organizing files. Usually, they require their own folder placed in the user directory and not all support selective sync. That's OK because symlinks solve both problems.
In the case of folder location, who cares. Unless you want to sync your whole home directories contents (ie I prefer to be more selective about backups) that's a good place for it.
As to 'what' you sync. That depends on your preferences. Personally, I prefer to keep things like game saves, software development projects, documents, portable software, and configurations synced to the cloud while syncing photos to a different service that is more tailor made to imagery.
I recently had my main desktop computer (ie an iMac) experience an internal hard drive failure after 6 years of use with 0 data loss. Sure, I had to reinstall the OS, applications, and re-link everything but it felt good to have a fresh start and I was able to script much of the process to make it easier to do in the future.