I use my main developer box and a main laptop the same manner: they run Linux, and I expect to do two things on them:
The main problem is: modern software suck. They grow like cancer (thus the name of this project). With each upgrade they are megabytes larger, stuffed with features that I didn't need or want and new bugs. Since I have a rather unusual workflow (not using X but text console most of the time), I am affected even more because developers don't test their software on environments like this which means upgrades break my workflow more often than they break the usual X11/desktop workflows.
For the normal work, I typically don't need to upgrade software too often, especially not for new features. So the above daily/extra split can also be articulated as "base system" and "extras", where I want the base system as an old, stable, reliable workhorse.
Normally I'd want the extras the same, but there external environment pushes software upgrades on everyone. A web2.0 browser older than 3..4 years is practically unusable. Which forces me to upgrade it more often than I really want to. Such upgrades unfortunately force me to upgrade my normal work software too, as these are all on the same system: new browser needs new version of the libs or even the distro I am using which will upgrade the stable workhorse part whether I want it or not, which almost always breaks something.
Of course I could run the extras in a virtual machine or container of some sort. The safest solution is a full virtual machine (e.g. qemu-system), but I dislike the idea to have a second desktop within or next to my normal desktop. I could use some sort of out-of-the-box container technology, but they are typically rather bloated with dependencies affecting the host system. I could use chroot, which I did, but with chroot I have to do mounts before entering the chroot and if any process is left running within the chroot it likely blocks the unmounts.
I've developed this software, called cancer to solve this problem. It is a bit like chroot, but most notably mounts are inverted. In chroot the root of the filesystem is replaced and I have to do a few bind mounts to make sure the chroot environment sees the same /proc, /var, /tmp, /home as the host. In cancer, on entering the new environment the root of the file system remains the host's and I explicitly do the mounts to change /usr, /lib, /lib64 to the "chrooted" installed variant. But more importantly these mounts are happening not on the host system but inside the new environment.
PIDs, most of the root file system, access to host resources (/dev, /proc, IPC, shared memory to X) are all the same, not virtualized, not hidden, not blocked. This way it's possible to execute a bloatware in a way that it sees only its own libraries and data files, but in every other aspect it plugs into the host environment, running on host's normal X11. With a launcher wrapper script on the host it's easy to make the whole thing transparent: I start chromium and it comes up, on my normal X11 desktop, operating on my normal home directory and /tmp.
Conclusion: this lets me keep a stable base system where I do most of my work; this base system can be old, or of a minimalistic Linux distribution. In the same time I can keep one or more somewhat virtualized desktop Linux installations with bloatware in them. And most importantly this lets me run the bloatware directly from the stable/small host system, integrating it into the host environment, without having to deal much with the fact that it's coming from a different distribution.