tl;dr Automapper kills traceability making software maintenance increasingly difficult. It's also a gateway drug to a bunch of anti-patterns.
I've turned from an AutoMapper advocate to a strong opponent over the course of about a year.
At first it seems like a great way to reduce stupid repetitive code. It accelerates initial development.
All is good and well until you have to change the application and all the nice tooling that helps us refactor with confidence breaks down because it cannot see the implicit coupling between mapped objects.
Compiler checks are gone.
Traceability is gone.
Debugging is next to impossible.
Profile validation to the rescue?
AutoMapper allows you to mitigate this to some extent by grouping mappings into profiles and then asserting that the profile is valid, meaning that all properties of the destination types are mapped.
This however requires that any unused properties in the destination type are ignored. If mappings address only a subset of fields on your types this will lead to lots of custom configuration code in your mappings, essentially defeating the main benefit of AutoMapper: less mapping code.
AutoMapper is not free
AutoMapper was hailed by some as the solution to ease the implementation of strictly layered architectures and later DDD. Decoupling layers or domains is impossible without mapping or transforming from one model to the next.
While AutoMapper can indeed help ease that burden, I'm inclined to agree with Greg Young that all this mapping is painful and if you really want to do this, you should feel that pain.(See 8 lines of code by Greg Young, skip to 39:00 for the bit about AutoMapper)
All that mapping magic does not come for free. Besides the maintenance issues mentioned earlier, AutoMapper also has a performance cost.
Setting up a lot of mappings is expensive as expressions need to be compiled on startup. Once that is done, AutoMapper is still nowhere near as fast as straight up hand written assignments.
Have a look at the performance comparison offered by AutoMapper alternative FastMapper (FastMapper on CodePlex, scroll all the way down for the performace comparison).
In an average application a bit of AutoMapper won't hurt, but once load increases it can definitely start to make a difference. A concrete case I saw was in a message driven application where large volumes of messages were being transferred during upgrades on deployment of new releases. Performance analysis showed that AutoMapper consumed between 10 and 20% of the CPU time.
A final word
I have stopped using AutoMapper completely and have not regretted that once. Hand authored mapping code is faster, easier to understand and easier to maintain.