In my experience, whenever a .so was missing it was either due to a missing package on the os package manager level, or a completely broken gcc or llvm setup. I never needed to explicitly add single .so files to a path. (Besides the use case where I specifically wanted to override a malloc implementation.)

In which cases did/do you need to add individual files?

in this case it's an in-house monstrosity that's got a lot of various languages and build systems involved, and the moment you update a compiler or build system, everything jumps into a new location for no good reasons. it was just an example though - same issue with .h not found during compilation, or using a different compiler from the system wide one.

In my case, I work with proprietary EDA tools. Vendors love messing with LD_LIBRARY_PATH. Chaos ensues when they override a system library or two versions require mutually incompatible versions.

I agree with the comment you are replying to. Having broken my home Linux installs too many times has taught me how to diagnose and fix this sort of issues.

In my case, when I was a Slackware user before Slackbuilds was created, sometimes I wanted to try out programs for which there was no package. Usually they required a .so file that was not installed and a workaround was to put it manually from a package of another distribution compiled for the same architecture. When the .so file was there, but on another path, a symbolic link was sufficient. The ldd command was a good friend.

Of course that was not the best and cleanest solution, having things outside the package management system bothered, but it was enough to experiment programs and I kept track of the changes so I could have the prior state of things. Later on, the Slackbuilds project eased the work and I contributed by writing code to automate the creation of a few packages. I learned a lot from these issues.