The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process them together. The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
In an anemic domain design, business logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in Java applications, possibly encouraged by technologies such as early versions of EJB's Entity Beans, as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).
Supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often). A rich domain model needs to be changed if any of them change. The anemic domain model may separate the changes and keep the interface between the data and the domain model containing the logic stable. But many developers think that it is not correct interpretation of Single responsibility principle. In case of rich model there will no multiple responsibilities, only single one. Each domain object will be responsible to managing of instance with some information inside. Otherwise, some other inner action (for example, construction of object) can also be considered as different responsibility. But it is pointless and therefore single responsibility principle should not decompose model to classes with Encapsulation_(object-oriented_programming) dropped.
Results in stateless logic which is inherently simpler and more scalable.
Needs a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
Needs a service layer when sharing domain logic across differing consumers of an object model.
Makes a model less expressive and harder to understand.
GRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data