Yeah! More accurately just EC, no real systems here.
Roguelikes are highly deterministic and are not real-time, so a system updating all its respective components for every "tick" wouldn't really fit.
The biggest obstacle with roguelike development is the way the components that make up an entity have to communicate in an agnostic way. Think if a wizard tries to freeze a warrior, where in the code/flow do you specify if that is or is not allowed? And what happens when you have extreme edge cases like if a specific area, a status applied to a teammate, or some random event nearby maybe says that the warrior is actually immune to being frozen? And what if the wizard's freeze spell is so powerful that it can ignore all of those obstacles?
The approach I went with is that the EC side is relatively basic but all the components can optionally tap into a flux/redux-style event system, and those messages are very powerful in how they allow themselves to be modified or permitted/allowed while being deterministic.
(And of course the message system allows for easy client/server logic, and super easy unit or integration testing of gameplay systems which hasn't felt like anything I've used before.)
I'm quite liking it so far, hoping to have something more concrete in 5-6 months.