That page seems to be more about the entity-component architecture (entities are composed of components, which define data and behavior for one aspect of the game) then about entity-component-systems architecture (entities are composed of components, which are pure data; systems can query this database). Traditional Unity, as that site points out, is EC; Unity DOTS is ECS. Not sure why the site would be the bible on the topic either as it only some surface-level information and links (and hasn't been kept up to date much).
Wikipedia has some links to some more recent approaches. The biggest problem (and the reason why you don’t see medium articles about it) is it’s extremely difficult to sell in the enterprise. Even if it is the right architecture. Most developers can’t grok it because of the MVC issue you already alluded to. My biggest advice - crack open VSCode and write one. You’ll learn more by doing. Forget games. Try writing a database. This is what it is really. How do you handle 100,000 objects that interdepend on a web of code? Start basic, arithmetic. Components can add, subtract, etc. end goal is query the scene for Fibonacci sequence entities.
Bonus points for updating (randomizing) values and picking different entities next tick.