Well, there are a few plausible reasons.
The first and foremost, there's the small issue of compiling...when you're compiling All The Things, sometimes you hit upon a package that likes to consume All The RAM in the process. When you're building VMs, you want to give the VM as little RAM as necessary for it to fulfill its function effectively. Obviously, there's a bit of a disconnect; it doesn't make sense to build something whose build process requires 6G of RAM when the normal services on the machine won't take more than 512MB.
Granted, it's only LibreOffice and Chromium whose build processes like to consume RAM like a leaky malloc in an inner loop, and I don't have a need to run those in a VM, but it feels safer to head off a possible trend toward heavier build processes conflicting with other VM requirements...which is a strong argument against Gentoo as a VM guest.
A second issue about running Gentoo as a guest is the sheer size of portage. Portage is the set of files representing the database of available packages and versions, and it can be anywhere from 1GB to 16GB. The *default* disk image size when creating a VM in virt-manager is 8GB, and that's an issue.
The first issue, that of compiling, is resolvable using binpkgs; you can build a package in one place and install it in another place. So I'll probably wind up using binpackages compiled where CPU and RAM is plentiful.
The second issue, that of the size of Portage, is also fairly easily resolvable; I can mount the guests' portage database and distfiles from the host via NFS.
Still, it sounds like a lot of work. What's the gain?
Let's start with what makes Gentoo nice in the first place: I don't have to enable features when I don't need them. Look at any Debian or RedHat server, and you'll find loads of code that isn't mission-critical. X11 libraries, graphics munging libraries. Media. When you'd like to fit useful services into slivers of RAM on a server, it makes a difference.
Gentoo also tends to have more recent versions of packages available than Debian/testing or (for sure) RedHat/CentOS. Yes, you can run Debian/sid, if you desire; I don't care to. Yes, you can install EPEL on RHEL/CentOS and tack on a number of additional repositories, and rebuild from srpms the packages you still can't find in a useful state...Gentoo makes coping with that kind of problem easy and more automatic.
Finally, at this point, it's the distro I'm most familiar with. I can make it dance and sing.
 I've never done this before primarily because my work-related interests at the time encouraged me to learn and work with Xen...now they don't. I may well play with Xen again in the future.
 The database is well under 2GB, but downloaded packages get stored in a subfolder, similar to /var/cache/apt/ on Debian.
 Perhaps there once was an argument that this wasn't at all relevant in a production environment, but if you think about it, the Modern Cloud is about running dozens of instances of the same thing, with more instances added as required to meet demand. The more you squeeze out of an instance, the better your system utility.