Because it's a fool's errand. The resulting mess would be the lowest common denominator of all the supported packaging tools. All of the various language-specific package managers do not touch things outside of their domain, leaving huge gaps to fill in. How would a meta-package manager know that installing the pg Ruby gem required having the PostgreSQL shared library and header files available at build time? What version of that library would it use? How would you reconcile where each package manager installs things? Traditional system package managers install to the global /usr directory. npm makes nested directory structures anywhere. Brew installs to /usr/local. How would you deal with the source vs. binary based package managers? Centralized vs. decentralized? How about package managers that require root privileges vs. unprivileged ones? What software bootstraps the entire system?
I could go on, but I hope you can see the futility. Even if you could somehow reconcile all of these things, what did it get you? You still wouldn't know the precise dependency graph of your software because most package managers can't tell you that. You wouldn't get build reproducibility because most package managers don't address it. You wouldn't get transactional upgrade and rollback of software because most package managers do not use atomic operations.
Guix can handle software written in any language, allows unprivileged package management, allows you to create isolated environments of packages (like virtualenv, bundler, etc.), deduplicates all packages system-wide via a content-addressable storage system, uses atomic operations for transactional upgrades and rollbacks, and more. A meta-package manager built on top the plethora of today's awful package management tools couldn't easily achieve any of these features.