Arguably the write-ahead-log that pretty much every SQL (and many no-sql) product uses is an event stream, allowing rebuild of objects (tables) in the event an instance fault. Granted most of them are opaque binary formats unsuited for application interrogation.
For that the ANSI standard now defines temporal features for SQL. This records the interval during which a particular value was valid. Recreating history is a matter of including an "as of" date-time value in the predicate. There are products specifically for storing time series data efficiently at volume.
The net result of all change is exactly what each table/ document/ columnstore provides to applications.
To answer the actual question - the outcomes offered by CQRS stores are mostly available from other, better known and supported products. The business risk of adopting one may outweigh the functional advantages so the products are not widespread.
CQRS can be considered a design pattern as much as it can be considered a product. As such any mainstraim store could implement a CQRS.
Accounting, banking and finance systems in general will store full information about each transaction i.e. each state change. Think of your bank statement - it has a complete list of all the credits and debits which occured within the reporting period. Chances are your bank uses a relational database to achieve this. I know Xero uses SQL Server. It is a tenet of double entry book keeping (accountancy to you an me) that no change can happen to an account without a transaction (ie an "event") and every transaction, once recorded, is immutable.