Actually, it is designed to have tunable consistency. You can have immediate (full) consistency if you choose. This is a common misconception. In practice, CAP is about trade-offs, as in any design of scale.

Tuning consistency levels for your requests (R/W/N values) can only guarantee read-after-write consistency at best. It doesn't guarantee strong consistency like what HBase provides.

Huh? Can you describe a scenario that you couldn't implement with tunable consistency levels?

Mostly the limitations people come up with with Cassandra are around cross-row ACID, which if you really need it you can do with LWT, though in practice the better solution tends to be to just denormalize in to one row and/or NOT actually require cross-row ACID. It generally isn't what you really need anyway. Most businesses don't really shut down just because they can't achieve consistency.

Simple use-case: you want to maintain a counter. In Cassandra even if you tune the consistency levels (set R+W>N), there's no way to correctly implement a conditional update. To elaborate further, you could successfully increment the counter in some nodes but fail on others and don't reach quorum (partial write). The next time you do read-repair, it's going to do LWW and propagate that update everywhere else. Meanwhile you think it has failed, and reissue the increment once again and so you've incremented twice. Alternatively you could have 2 competing increments racing each other and one of them wins and the other loses due to LWW (and you've missed 1 count). This is trivial to implement correctly in HBase since it offers strong consistency.

In practice, Cassandra gets around this issue by implementing a custom CRDT for counters. But CRDTs don't exist for everything and in general it's not trivial to get things right. I'm not arguing Cassandra is bad, but it's a misconception that you can tune the consistency levels and somehow get Cassandra to behave like a strongly consistent store.