Because otherwise, your domain model is not able to express which states are valid. A core idea behind encapsulation is that by controlling state mutations, it is possible to enforce invariants, thereby making invalid states impossible to construct. This idea is not unique to object orientation; for instance, in the static functional programming community, this is known as "making illegal state unrepresentable" [1].
By creating a "dumb" domain model and allowing business rule modules to do arbitrary mutations, each model is required to know about and enforce the domain model’s invariants itself, which dramatically increases the amount of code that potentially can break these invariants, and thus needs to be debugged if something goes wrong.
> Taking this a step further, you can have a business model project (class library/Nuget) that is shared across multiple projects within an organization.
This can work in some situations, but there are good reasons not to do this. Different teams may have differing and sometimes conflicting meanings for some of the terms of the domain (especially for generic concepts such as "user") as well as different data needs depending on the use case. This is why for instance Eric Evans’ "Domain-Driven Design" [2] argues for limiting domain model unification to "bounded contexts" [3] of which there may be multiple in the organization, and have explicit translation ("anti-corruption“) layers between the boundaries of these contexts.
[1]: https://fsharpforfunandprofit.com/posts/designing-with-types...
[2]: https://www.goodreads.com/book/show/179133.Domain_Driven_Des...