I haven't worked with UE4 much, and am only beginning to feel comfortable with Unity, but one thing I'm beginning to feel about Unity's framework is that the entities and components are structured very nicely, but they hide too many details of the underlying systems for my liking. How is each component stored in memory? How does each system iterate over its specific component instances, or its combination of multiple interrelated components? Ideally, not every component would be stored identically, or iterated over identically, or lookup up identically, et cetera.

It feels like the Unity team has done a pretty good job of adhering to the data-oriented design philosophy in some regards, but they've made many of the design choices already and hidden the details within the private portions of the engine. Which means that they've had to make generic design choices that work well enough for as many game elements and as many types of games as possible. Which then severely weakens a developer's ability to exercise data-oriented design effectively. The design depends on the data, and different games and different systems have and use data in vastly different ways, but a Unity developer can only do so much when trying to design appropriately. It's like Unity is so close to awesome, and yet so far away.

So I don't think that Unity has problems because of its purity with the ECS concept, but because of the genericity forced by the closed nature of the engine. Despite that, and as implied above, I do find it to be adequate. It's good enough, but it doesn't achieve the awesomeness that I think its overall design grants it the potential to become.

I think Unity's is a step in the right direction, but it's very difficult to make components interact when they are entirely encapsulated. I find that it's better to have components be pure data, with systems operating over them, potentially multiple components at once, e.g. an IntegrationSystem that integrates velocity into position, but only if both components are present.