Xen and KVM are similar in that both can be used to run _hardware-assisted_ virtual machines. The strategies are, yes, completely different - KVM uses Linux as the "uppermost" piece, and each virtual machine is just a process as far as the host Linux is concerned.
KVM is great, say, if you want to run Windows instances - None of them will know (well, except for the hardware self-description strings) they are running virtualized. Same thing, yes, can be specified to Xen.
However, Xen's paravirtualization funcionality is completely unmatched by KVM - Xen can run DomU (guest) kernels that are explicitly aware they are running under a paravirtualized environment. This, of course, excludes non-free software, as they would have to be ported to the Xen pseudo-architecture. However, it is a very popular way to run completely independent Linux systems.
Why do you want to paravirtualize? Because the performance impact is way lower. You don't have to emulate hardware at all - In a regular virtualization setup, the guest OS will still shuffle bits around to give them to, say, the ATA I/O interface, possibly aligning them to cylinder/head/sector - On a hard disk that just does not exist, that is a file on another filesystem or whatever. When it is paravirtualized, the guest OS just signals the host OS to do its magic.
My favorite way out for most of the cases I would be forced to handle with Xen for this kind of needs is to use vserver - Which is _not_ formally a virtualization technology, but a compartmentalization/isolation technology (akin to what was introduced as the BSD Jails around 2000), where many almost-independent hosts share a single kernel, but live within different security contexts.