A domain event describes something that already happened. It is a fact, not an intention. Yet many codebases publish events from inside the entity, at the moment its state changes, which couples the entity to infrastructure and lets you announce a fact before it is even true in the database.
Most architecture discussions treat the bus question as global. Either the whole application routes commands and queries through a CQRS bus, or none of it does. That framing forces a bad trade: pay CQRS boilerplate on a homepage that displays a greeting, or drop the bus on a module that genuinely needs events and transactions. The real unit of decision is not the application. It is the module.
In most PHP projects, cache logic ends up scattered across business code. The handler that executes the query also contains the caching logic: key generation, lookup, storage, TTL. Two responsibilities, cache code and business code, coexist in the same method.
In most PHP projects, transaction management falls on the developer. But a forgotten DB::transaction() or a missing rollback, and the data sometimes ends up in an inconsistent state.
In many PHP projects, CQRS is applied systematically. Every operation goes through a Command or Query Bus, with handlers, middleware, and event dispatching. For a homepage that displays three statistics, that is pointless boilerplate.
CQRS is not the problem. Its systematic application is.