Note that in most Linux distributions, the package manager not only forces a specific location, but it tracks them too.
For example, on Debian or Debian-derivatives like Ubuntu or Mint using Debian packaging, one can say for example
dpkg-query -L $(dpkg-query -S $(which foo) | cut -d ':' -f 1)
to find out what other files are in the same package that provided command foo; or just
dpkg-query -S $(which foo)
to find the names of the package(s) that provide existing command foo.
However, you most definitely can create Debian (and RPM) packages that use only the libraries provided within the package, in the same directory (or more preferably, a subdirectory), wherever it is compiled or installed to. In fact, it is trivial for non-SUID, non-filesystem-capability-using binaries; and you don't even have to recompile the libraries. All you need is to write a small wrapper that extracts its own absolute path, set the LD_LIBRARY_PATH to that directory (or suitable subdirectory), containing the libraries needed, and then execute the actual binary. (Privileged programs that change UIDs or use filesystem capabilities do need to be relinked, with DT_RUNPATH ELF dynamic section attribute naming the correct location, and -z nodeflib option so that standard ELF cache locations are not used as a back-up location to search in.)
(I've ranted before about how it is possible and not difficult to make portable Linux applications – that Just Work across most/all Linux distributions –, so I won't repeat that here. If anyone wants a practical example, though, just ask.)
You can also run binaries in a chroot environment (even bind-mounting existing filesystems or their leaf-parts to the chroot), but overall, a virtual machine is a better choice for that use case (since you probably want to protect the "parent" system from any shenanigans those binaries might do).
It is the same old story: with Linux, you can do whatever you want, but either you do it yourself, or you get someone to do it for you. Ain't no free lunch.
By this I mean that if you want to use Linux as a tool in a production environment, you should have someone – paid, contracted, whatever – to do your support for you.
In an optimum situation, that someone or those someones also continually optimize the Linux environment you use for your workflow(s), too.
But try and get pointy-haired bosses to go for this! At least, I myself am not enough of a salesman to get through the PHBs, even showing past proof of it working.
It seems like whenever you mention Linux, they think "no cost". No, there is always a cost, and one should compare the cost to the tool you get for that (ongoing) cost, in terms longer than a quarter year.