1. Most importantly, VProbes is safe. Using a kernel debugger or something from within a guest provides some very dangerous opportunities: e.g., you could poke a hole in a critical guest memory structure. Also, kernel debuggers usually stop the target program to allow inspection. VProbes keeps things moving along while data is harvested, so it can be used even on mission-critical, highly available systems.
2. VProbes doesn't rely on any in-guest tools. If the target is, for instance, an appliance that doesn't even have a login shell, let alone /usr/bin/top, VProbes works no better or worse.
3. It doesn't care what state the guest is in. If the guest is hard hung, or is swapping too hard for a shell to come up, or whatever, VProbes can be a "tool of last resort" to try to harvest information.
4. VProbes is also immune to guest attempts to fool it. For instance, malware often tries to change in-guest instrumentation tools to make itself undetectable. Since the VM/hypervisor trust boundary protects vprobes, it is immune to this weirdness.
5. VProbes is neutral as to the identity of the guest; since it's machine-level, you can use the same tools for Windows, Linux, Solaris, FreeBSD, MacOS, etc. To the extent the preload scripts work, even some common, but OS-specific, notions, like processes, can be captured.

I think books about concrete operating systems are more useful than the academic texts, which tend to spend too much real estate on ideas that turned out to be dead ends. Solomon and Russinovich's Inside Windows 200X series are excellent, providing broad, deep, well-written insight into the most commercially important operating system out there. I haven't seen anything quite as great in the Linux world, but Love's Linux Kernel Development is just fine.