As a game developer with over 25 years of experience, let me assure you that Entity Component Systems exist and are popular for good reasons. Performance is one key benefit, but also an ECS achieves a kind of data normalization similar to SQL databases. This relational model affords flexibility that is difficult to maintain in OO systems.
I'd take a Rust ECS over a Love2D engine any day. With the freedom and speed of unopinionated Lua development, most developers (self included) will quickly paint themselves into a corner. Change will become difficult because the engine does exactly what you tell it to do, and you will contradict yourself as requirements and implementations change. The ECS will, of course, do what you tell it to do also -- but it will do so in a manner that is structurally consistent. Your way of telling it what to do is far more organized than evolved imperative code. This gives you greater control, makes change easier and more predictable.
Don't worry about Conway's Game of Life. It doesn't discourage ECS any more than it discourages a class hierarchy. Think clearly about what the evolution of state actually involves: a previous state, an action, and a new state. If you've seen implementations that make use of already-updated state as if it were previous-state, then those were simply naïve implementations. You can easily achieve correct updates by flip-flopping between two full states, but in some cases like Life where change depends only on local previous state, you can fill and use a small cache as you go along, using only a margin more than one full state.