The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented design;
The anemic domain model is really just a procedural style design,
In essence the problem with anemic domain models is that they incur all of the costs of a domain model, without yielding any of the benefits.
As I discussed in P of EAA, Domain Models aren’t always the best tool.
The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.
One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn’t an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
This layer is kept thin.
It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down.
The key point here is that the Service Layer is thin
Now, the more common mistake is to give up too easily on fitting the behavior into an appropriate object, gradually slipping toward procedural programming.