Like you, I've seen both sides. Unreal lineage evolved from inheritance-based into ECS-like. Frostbyte is heavily ECS.
Googling... the author is ex-amazon, ex-microsoft - with xbone and 360 title experience. Perhaps the author was exposed to that pattern at one of those institutions, or perhaps the author saw the 2018 Rust Conf Closing Keynote and was inspired to continue down that path.
I think people tend to either go with what they've seen work in the past, or heard works well. Maybe it's cargo culting, or maybe in the case of rust (which I have no current experience with), it helps? Either way, the most important point is to focus on the fun and not let technologies get in the way of making a good game.
 - https://www.youtube.com/watch?v=aKLntZcp27M
It's definitely fun to play with new programming languages and technologies. Using games as a medium to explore a new language is a great way to learn and have fun at the same time. That said, when a game development luminary like jblow takes the time to make a comment, it's good to think about why.
It seems to bother jblow that people are buying into the use of this system without thinking about the costs as well.
Its the same as the debate about when it is the right time to move to a distributed microservice architecture from a monolith. In this case, the use of an Entity Component Systems in a small game could be compared to the choice to use a Distributed Microservice Architecture for a small application.
Monolithic applications are easy to build and maintain by a small solo developer/shop, but they don't scale as well as you increase the number of engineers and expand the scope of the product. So a monolith is split into domain specific distributed microservices to allow for an increased number of developers working in parallel. When you pick to employ this tactic is up for debate.
Building a distributed system is hard. Debugging a distributed system without solid tooling/tracing is even harder. In the microservice world we have a lot of tooling to help us. Games, usually much less so. Where you might use GRPC in microservices and have stuff like OpenTracing to lean on, in games with Entity Component Systems you'll usually have some form of a message bus/event system without the same level of tooling and tracing.
Entity Component Systems/Distributed Systems are a useful pattern to implement when your desire is to build a reusable generic game engine/application to be implemented by large or scaling engineering teams. That's why you see these patterns employed and used by large game companies/startups and game engine/SaaS developers.
In summary, perhaps jblow's point is that small/solo developers can build a good game/application without employing the ECS/distributed microservice architecture pattern. And like you said, it's also useful to try building/using these patterns in toy applications to gain experience.
While building a game using some inheritance based approach, one will quickly hit limits even with a single engineer, whereas a monolithic web app can scale to a team of a couple dozen engineers easily.
Please stop saying this stuff as it just contributes to the general confusion.