It's also a cherry picked example, networking code, of a problem that can be expressed equally as nicely with OO or functions. Now refactor a gui or a game without OO and you'll find the OO version easier to understand or cleaner.
ECS doesn't represent game objects with standard OO such as classes in C++/Java/C#. You can argue about whether it's still OO in principle, but it's not the kind of OO an enterprise developer would recognise.
[1] http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal...
https://ericlippert.com/2015/04/27/wizards-and-warriors-part...
For card games, OOP is very well-suited (so to speak).
In a "noun driven domain" you can still disallow the noun to perform the verb.
It's not a question of can they, or should we prevent them, it's 'should it be required?'
It may make sense to require all verbs to be coupled to a noun when your problem domain is mostly modeling nouns, and verbs only describe how those models change and interact with each other. But when the problem domain is mostly process, with nouns being ancillary, it is unwieldy to talk that way. It's why you have so many "ThingDoer" and "Utils" and the like in most OO codebases.
made me chuckle — that’s my day job! Check out RamdaJS btw