If you're interested in the subject, I also recommend reading the book "SystemVerilog for Verification" ; it is "the book" on the subject, and although it teaches VMM, it's an excellent reference on the concept of verification to begin with. (It suffers some from the same problem that Kent Beck's Test Driven Development book has -- it verifies excessively simple things -- but IMO, the techniques that it teaches scale much better than Beck's techniques inasmuch as they're actually possible to use in real world applications.)
 For instance, for some laughs, take a look at the API reference for the channel datastructure, vmm_channel: http://www.vmmcentral.org/uvm_vmm_ik/files2/vmm_channel-sv.h... -- there is just so much bizarrely wrong that I can't even list it all. "Sneak" is a good place to start, though...
I loved working with RVM and VMM, as to me channel-based transaction (and transactor and scoreboard) programming is very natural and simple to understand. And it's the route that newer languages like Go have taken.
UVM (and all the predecessors) have gone the route of TLM (transaction-level modeling), which has no explicit channels. So many of the objects talk directly to other objects, which adds unnecessary coupling.
However, the big thing that I dislike with UVM is that it is basically Enterprise Java for SystemVerilog. They have made the API's into this cookie-cutter complex enterprise abstraction, where you have to follow the macros and recipes per the book. Everyone must use the built-in macros, and use packages and factories and sequences and agents and virtual components. And your employees start talking in UVM-speak ("oh that's in his UVC").