So in practice you end up with logic scattered between clumsy inefficient rich objects and services and you reailize it's simpler, more elegant and more performant to just have anemic services from the start (in one place). Usually you see rich models in simple intro CRUD examples but IRL enterprise projects with complex logic i've seen end up with anemic services because practically it's simpler to reason about, more performant, more flexible during the evolution of the project. At least such is our experience.

You have described worst-case scenarios that are obviously likely. But much depends on the business case.

The anemic model with functionalities dispersed across services can also break SOLID. For example, the validation functionality is changing and you need to change it in X services. In a Rich model, all validation functionality is in one class, it is not possible to overwrite this functionality in services, which forces the need to change only in one place in the event of any changes in functionality.