Here's another one I've had that I'll throw on the pile: video games are generally highly demanding of the CPU. They'll use every cycle they can get their hands on. Web apps, on the other hand, have a ton of downtime and generally don't need to hit 60FPS (with rare exceptions). This means that they can spend their extra cycles on better abstraction layers, like React and Redux. Using React to render a bunch of game entities would make no sense because just running the reconciliation step can take 16ms, which is your entire rendering budget.
Unity has a lot of warts like your article indicates, but it gets a huge amount of bang/buck producing a not-big-budget multi-platform title with a multidisciplined team. I think that provides a lot of value for developers; so much that it outweighs the snags involved in Unity's technical shortcomings. Unity's roadmap is probably about expanding shipability for smaller developers and why Unreal is trying to commoditize that with Godot.
I feel like Unity's "entity as a container of components, things are OO'd and there's a lot of polymorphic dispatch / existence checks / branching" is starting to feel out of fashion as of late, and the ECS approach is something folks have come around to.
I've been playing around with such an engine for a side project. Here's a quick video -- https://imgur.com/a/BcnWJha -- you can see what the in-game editor looks like + some of the physics of the game (the game and editor run both in web and natively). I think with the ECS-queries approach the code comes out to be quite ergonomic. For example, I've highlighted the logic that makes the player be obscured by objects in front of them here: https://gist.github.com/nikki93/8cc5d99e45ad74e7f1053dbef287... The game-specific code for the whole game is in that 'main.cc' file and comes out to about 500 lines. The game also includes custom inspector UIs for the 'Sprite' and 'Feet' components that are defined right in that file on line 288-314 and you can see them in the video.
I tend to agree, and I think it's something that doesn't get promoted enough as an advantage of ECS compared to cache hits and parallelism. When a programmer wants to add a new feature to a game, they can slot their system into the game's tick and avoid stepping on their peer's work as much. They won't need to edit `Entity.cs` or an inheritance tree, and it's much easier to reason about the order of updating game data per frame. It also makes code ownership and code reuse a bit easier to divide up too. I'd take an ECS system even with a performance penalty, as the organizational benefits really add up over time.
Traditionally, a video game has a point where development stops and is never resumed again. In the past this might have been lot check or "going gold"; today it might be a few post-release patches. There's a point where you don't keep working on your entertainment product and resources are invested elsewhere for more revenue. I think this means that the value of paying off structural technical debt might be always less than the revenue from your first month of sales. I think that changes the decision-making of management as their game's performance might be better off with a month of heroics and duct-tape rather than missing a holiday release date. I don't get the impression that profit incentives are the same with most typical web services.
There are big exceptions to this, of course. Many more games are service-based these days. I think we're starting to see them adopt more stable practices like the rest of software engineering at both big [2] and small [1] scales.
[1] https://www.youtube.com/watch?v=t9HRzE7_2Xc [2] https://www.gamesindustry.biz/articles/2017-08-04-bungies-13...