qemu-kvm just has some threads that represent virtual CPUs. These threads and their resources are managed by the Linux scheduler, the Linux virtual memory manager, the Linux power manager, etc. You can use the regular tools such as cgroups to tune VMs, to distribute
On Xen you have two levels of scheduling and two levels of memory management. Xen distributes CPU shares to all domains (including dom0), and dom0 distributes CPU shares among its processes. Xen assigns memory to all domains (including dom0), and dom0 distributes memory among its processes. It's much harder to use a Xen dom0 for non-VM-related tasks, because you can only partly control the resources that dom0 receives.
For power management, Xen has to ask dom0 to process ACPI tables and basically summarize them to the hypervisor. It's even more complicated when it comes to paging, because Xen doesn't do paging on its own---it asks dom0 to page stuff in and out.
Sure, the Xen architecture seems simpler (because you "just" have to handle VCPUs, not arbitrary tasks, and because you "just" have to share memory among a few dozen domains rather than thousands of arbitrary tasks). And to some extent it is, because inventing a new scheduler or memory manager trick is much easier on Xen than on Linux. But in the end I think KVM's performance and simplicity proves that it is not worthwhile, also because every improvement done to favor KVM (think of Andrea Arcangeli's transparent huge pages and AutoNUMA) will benefit every workload, and will effectively have double benefit if you can use it to speed up both the host and the guest.