Well, I mentioned one: no need to bless things. In a language with true OO support, there would be a mechanism allowing you to serialize and unserialize objects. We don’t have that in JavaScript, which means that the app programmer is responsible for doing it. That makes lovely provider methods like:
allWidgets(): Observable<Widget[]> {
return this.http.get(api);
}
…turn into twisty mazes of needless new and copy constructors if Widget has to contain a bunch of methods.
It also just fits better into the way I think about things. Chefs cook meals, not ingredients, and so service providers should contain all the logic, letting data just sit in dumb PODOs.
Another problem that I always found myself banging into is that eventually I needed a reference to something from within the “smart” data object that is managed by DI, and at that point you hit a serious wall. Now I have to build some sort of bridge that allows me to inject helper objects into these data objects. Since the service provider either is that helper or can easily inject it, why don’t I just move all that stuff out of the data container and into the provider? That’s what I always ended up doing and so I define data containers as interfaces to help me resist the temptation to put methods into them.