Cool Verification

1. I never came across any major gotchas in the language.  Everything I wanted to do I was able to do (eventually).
2. I found Vera constructs such as mailboxes, ports, and interfaces quite useful. 
3. There was no requirement to use any of the RVM libraries with the bench I was working on, so I never got around to using them.  I did look through them but figured the things I might have found useful were not exactly what I wanted, and I would have had to recode them anyway.  The one feature I would have been able to take advantage of was the RVM channel, but I was able to work around that by spending a little extra time passing around mailbox IDs through the hierarchy.
4. get()/set() methods are popular when using an OOP methodology.  The RVM doesn't recommend using them because they can interfere with the ability to constrain and randomize member variables.  However, if you don't use access methods, difficulties occur if you end up needing to customize the way certain variables are accessed in derived classes.  In my experience on my latest testbench, I ran into trouble whenever I forgot to include the access methods.  However, I found it annoying to have to add an extra pair of methods for every protected member variable I added to a class.
5. Vera AOP is not the same as "when inheritance" in 'e'.  The only way to create multiple permutations of a class in Vera is to use object oriented techniques.  For example, if you want to create a base class called "EthernetPacket" that can have Ethernet2, 802.2, or an 802.3 SNAP header, you'll have to build up an object using composition that has an EthernetHeader object as a member variable.  Using "when inheritance" you can quickly extend the EthernetPacket struct to have the appropriate characteristics depending on which type of header has been selected.  I would tend to agree that the end result in a Vera bench would have a cleaner set of interfaces and would make for a nice UML diagram.  The tradeoffs are that you need to have more skill, more patience, and be willing to write additional code to get the job done.  You also have to be willing to tear up portions of multiple classes if you need to add a feature late in the design process.
6. Vera doesn't have any way to differentiate "physical" fields from what I'll call "control" fields in an object.  Often objects will have fields used to store information read from the DUT and other fields used to store things like whether the object was generated by the checker or the monitor.  I ended up having to write a custom comparison method so that my scoreboard could compare objects without worrying about the control fields.
7. The paradigm of having to explicitly configure an object to use randomization causes developers to build testbenches that are less random.  Granted, I happened to be building a bench to test a specific set of DFT features which had little need for randomization at first.  The problem was, by the end of the development effort I'd created an environment where randomizing something like error injection was more difficult than it might have been otherwise had I been thinking about randomization the entire time.
8. I ended up having to write a significant amount of infrastructure in the form of base classes before I could really get started building the core part of the testbench.
9. UML diagramming tools help with early testbench prototyping, but are limited in their usefulness since they don't support generation of Vera code.
10. Though the Vera language is similar to Java, I had a difficult time finding a development environment that was anywhere close to that used by most professional software developers.  The best I could do was to use Exuberant CTags and the taglist.vim and minibufexpl.vim vim plugins.  Unfortunately, e and SystemVerilog are no better (actually, much worse).

In the end, the bench I developed was one of the more architecturally interesting benches I've written.  Be aware though that you need to be willing to invest in the effort to train yourself or your team in OOP techniques and to develop a robust set of base classes on which to build your environment.  Otherwise, you'll pay the price at the end of the project when you find yourself with a bench that is difficult to maintain or carry forward onto a future project.