I absolutely understand the point, using traits needs to be something well thought. However, it does help me for classical usages like Doctrine extensions. I feel it suits really well some use cases like this one.
About entities, there are two possibilities: either you can have anemic entities or rich ones. Having rich models is useful as it expresses a large chunk of your business domain directly in the entities, centralizing the important parts of your project in the same place. However, it requires a much more complex software architecture based around entity events to achieve great results, as your business processes will always need other services unavailable to the entity itself.
I think anemic entities are not the ideal, but they are pragmatic and efficient. They fits really well in Symfony Forms and they are easy to understand and manipulate for newcomers.
I usually have a combination of both worlds: I try to express small logic in my entities (for instance, User::enable() instead of User::setEnabled() and User::setEnabledAt()) and I like to have what I call a “workflow service”, which aggregates all the more complex processes related to this entity in one place. For instance, I have a UserWorkflow in which I have an enable(User $u) method, enabling the user and sending him/her an e-mail.
I like this organization because it is simple (it relies on simple method calls instead of events) while still being close to what rich models use. But that’s my opinion :) .
