CQRS enables distributed applications to not only scale horizontally, but independently in their write and read concerns. The replicas of query service, for example, can be different from the number of command services.

The read and write load in enterprise applications is usually not evenly distributed. Typically the read operations highly outperform the number of writes. For these cases the number of read instances can be scaled out independently. This would not be possible in a CRUD-based system.

Another benefit is that each service can optimize their state representations accordingly. For example, persistently storing the domain entities in a relational database might not be the best approach for every situation. It's also possible to just store the representation in memory and to recalculate all events at application startup. The point is that both the write and read instances are free to choose and optimize their representations according to the circumstances.

A side effect of this approach is also that CQRS provides read-side failover availability. In case of the event store being unavailable no new events can be published, therefore no use cases that modify state can be invoked on the system. In CRUD-based systems this would correspond to the database being down. In CQRS systems, however, at least the query services can still provide the latest state from their representations.

The state representations of CQRS systems also solve the scalability issue of event-sourced systems. Event-sourced systems calculate the current application state from the atomic events. Executing this each and every time an operation is invoked will over time become slower and slower as more events arrive. The representations of the command and query services eliminate this need by continuously applying the recent events.