Are Anaemic Domain Models really considered harmful?

In his book "Patterns of Enterprise Application Architecture" Martin Fowler describes the "Domain Model" as a complex approach to organizing business logic. The method consists of the consciousness of classes corresponding to domain model objects in data structure and behaviour. At the same time, technical aspects such as data storage, authentication, and authorisation, transaction management are taken out of the business logic.

The pattern is implemented in two ways: 1) Rich model — data and behaviour are encapsulated inside domain objects. 2) Anemic model — only data is encapsulated in the objects of the domain model, and the behaviour is transferred to a separate layer of services.

Fowler and Evans consider the anaemic model to be an antipattern. However, a lot of codebases the speaker has worked with are implemented in the style of the "anaemic" model. Many teams reported that they had hard times implementing the “rich model” and have never succeeded. Is it just a lack of expertise or it’s something with the pattern? This talk is dedicated to the comparison of the firm and weak sides of both approaches and non-obvious details of each implementation of the domain model in the OOP paradigm and the functional programming style.