Just don't do eventual consistency if the domain doesn't allow for it and if performance is OK. From a functional perspective there is no need for it in CQRS/ES systems.

However ... if going with eventual consistency, it's essential that the write side is consistent. The read models - not so much. This is because every aggregate (... if Domain Driven Design terminology is your thing) represents a transactional boundary within which state needs to be consistent in order for the business rules to work correctly. Read models are more forgiving.