At my current position, I don't need it. But having to install software as normal user (without increased privileges) seems to be a common theme when working at universities.
At the weekend, I wrote up a step-by-step instruction to install user-land the way I ended up doing it -- using our own isilmar ports tree.
There are two main ideas behind this approach (that is used both, to install custom software on our server, and to install stuff in your home directory).
The first is to automatise, i.e., document in a machine readable form. Even though for almost any program, it's just a simple configure, make, make install, followed by throwing away the work directory where things were built, things do add up! Think you changed a library and want to "just rebuild everything (depending on it)". An then, on top of that, some software might need special configure options, others need to be patched, others...
So, one rational way to organise it is to have a Makefile describing the general pattern of how to install software. And for every particular piece of software to install you have a (directory and a) Makefile describing what is specific to that very program (like the URL to get it, additional configure options, etc).
The other main idea is to use stow(1) to manage packaging. Essentially, you want a a traditional layout (one directory per package). That's great! The tool to find out which packages you have installed, and what files they consist of is simple ls(1), the tool to create a new package is mkdir(1), and the tool to delete a package is rm -rf. All built into your base operating system! Oh, and everything is installed to the final destination. Simply setting PREFIX is enough; the installation process may hard-code the destination at as many places in the code it likes. That's much easier than to manually add DESTDIR support to an installation framework that wasn't build for it.
The only disadvantage of a traditional layout is that you have to add a new entry to you PATH environment variable for each and every package you use (as they all bring their own bin directory). And the same for MANPATH. And more paths. That approach is actually taken at quite a few university clusters, where different groups need mutually incompatible versions of the same binary. But in most cases this is just too inconvenient, and that's where stow comes into play. It simply creates a common directory hierarchy (with bin, man, ...) and populates it with symlinks to the contents of the individual packages. So you can keep your PATHs short, while still having the advantages of a traditional layout.