I agree that the SQL and Exchange should be on mirror + stripe. That that provide roughly 90*6= 540 Write IOPS (when ZIL or your case a SLOG is flushed) and 840 random reads. We typically see a 90+ % cache hit rate in most workloads. This is also dependent how much main memory is deployed. I would recommend a minimum of 24GB of RAM.

For the second box I have a hard time recommending RAIDZ2 for a virtual workload with that few of spindles. This because each Vdev performs like a single spindle. So a single 12 drive RAIDZ2 will give 90 write IOPS or 90 cache missed read IOPs. If you have a pair of 6 drive RAIDZ2 you will get 180 write IOPS when your SLOG is flushed and 270 IOPS on cache misses.

I would configure both systems as mirror + stripe. We have over a hundred units deployed and have around 5 raid z arrays deployed. The only time we deploy Z2 arrays are for CIFS archive or backup. The vast majority of our systems are deployed as Tier one HA Clusters for virtual workloads.

We have also deployed a few OCZ Talos C series drives with mixed results. When you run a !bash y
iostat -En

The have a ton of soft errors. these are all correctable errors that drive retry's the block. The other thing we have noticed is as the L2ARC is filled which it designed to the drives can become slower than spinning disk. If you want to keep the OCZ in production you should put a 100GB slice for L2ARC.

The OCZ could slow your benchmark if the test was run long enough to fill the device. The other factor is block size. there is a relationship between block size and the amount of main memory is required to drive the SSD. For virtual workloads 128k blocks should be used to reduce metadata and and utilize more memory for cache rather housekeeping.

the on board NICS which are broadcoms need to be disabled. That could also cause the system to act up.