It's very easy to do CQRS without Event-Sourcing. ES is really a separate kind of architecture-piece that's concerned with how you mutate your persisted data.
For example, at work I've got a CQRS system where the MySQL database looks pretty much like you'd expect from any other system. (Customers table, one row per customer, etc.) It's still CQRS because writes and reads occur through different paths, and writes can have side-effects to proactively-build readable data. For example, "Top 100 Happiest Customers" might be its own table--managed by application code--rather than view or query.
Not sure exactly what capability you're referring to with the "famed" scalability, but my point is that CQRS in no way requires Event Sourcing, and offers its own set of benefits. (It's also a helluva lot easier to do, or un-do.)
In particular, CQRS helps you make a sane architecture for "read models", where certain features (say, a homepage showing a hard-to-calculate leaderboard) are simple queries against a data-source designed specifically for that feature. The backing data-source is kept up to date by application code as a side-effect of your "real work".
This means you can substantially reduce the runtime load on the database as well as reducing how much application-logic "leaks across" in triggers/procedures/views. Since your database is often the "bottleneck of last resort", this means better scalability.
For example, at work I've got a CQRS system where the MySQL database looks pretty much like you'd expect from any other system. (Customers table, one row per customer, etc.) It's still CQRS because writes and reads occur through different paths, and writes can have side-effects to proactively-build readable data. For example, "Top 100 Happiest Customers" might be its own table--managed by application code--rather than view or query.