I think the best practices is to exclude the exchange 210 DAG environment from the MC operation (use of SyncMirror) :
Create 2 specific aggregates for Exchange 2010 DAG environment 1 on site1 an the second on site 2) and don't use "syncMirror" to synchronise these agregates, use only the Exchange 2010 replication process.
I think Thomas talk about (FAQ MetroCluster - June 2012):
Can non-mirrored aggregates be used on MetroClusters?
Yes, non-mirrored aggregates can be used for both Stretch and Fabric MetroCuster. However, with Fabric MetroCluster all storage must connect through the switches (no direct attached), and with Stretch MetroCluster all storage must be seen by both controllers.
Also, non-mirrored aggregates will not be available during takeover and multi-disk failures on non-mirrorred aggregates can cause the system to panic, thus affecting overall availability of the MetroCluster.
phil is right, like described, unmirrored aggregates put the whole system at risk. Its not just due to automated crashes, its also due to administrative error since for a planned maintenance, the aggregates have to be offlined manualy, bringing a more complex action plan for your next site maintenance/planned power outage etc..
Usualy we suggest a 2nd netapp system with unmirrored disks for the "not so important" data.
Current concepts might have to be reviewed/rebuild when it comes to large exchange 2010 or sql 2012 installations.