Hmmmm.. So, AX is reading a record as type Table, Map, or View and can't convert it with the CIL because it can't figure out one of the field's type... very interesting. Can you paste the datasource types that were used?
That would have been easy enough to solve. We just would have needed to look at the datasource field types and figure out which one wasn't being read into a .NET type. You could do that through debugging or by just removing field by field and attempting the import/export operation until it succeeds. You would know the bad field type when you remove it and the import/export operation works. I suspect that this will be the cause of some of the problems, but not everyone's problem.
But something else threw me off on this one... The fact that it wasn't happening in all environments... Tricky.. Months ago, I remember reading about how the new 2012 AX framework could cause inconsistent behavior with Arrays across tiers! Shoot.. now, the metadata is involved in it. Check this blog post and then follow the instructions on how to debug in interpreted mode as you click the Excel Add-in and go through the process.
blogs.msdn.com/.../x-arrays-behave-differently-in-net-cil-in-dynamics-ax-2012.aspx
Remember that Dynamics AX is a weakly TYPED system, which means that the compiler won't catch certain errors and they will blow up at runtime.
I had not seen this variant of the Excel-Addin error, but I would start here if I were troubleshooting. Knowing that you have an incompatible typing error will help you look for a lot.
Also, a ton of 2012 errors were fixed with a full recompile (that has a lot to do with the AX 2012 way of processing an Excel command as opposed to the 2009 way), but I would debug the process first.
This isn't an answer, but I hope that it will get you on the right track.