The benefit of ACID transactions isn't just safety at the application level, it's the ability to compose abstractions and build complex data models on top of simple ones. For example, indexes in FoundationDB are typically more scalable than in the majority of other systems, where index queries often have to be broadcast to all the systems in a cluster. Yet FoundationDB doesn't even have indexes as a feature - higher layers build and maintain index invariants using transactions.
FoundationDB is also just really reliable and fault tolerant. Its testing story is drastically better than what the teams building these other products are doing.
Can't speak to HBase, but one thing Cassandra doesn't guarantee is ACID - I've seen some data consistency issues that has arisen from Cassandra in our usage, although it hasn't been a huge problem for us. That difference alone probably brings a lot of value to FoundationDB.
I’d like to see a deep dive of how foundationdb handles this. It has to trade-off consistency for availability at some point and it would be nice to know exactly where.
From my memory writes within a row are atomic. It seems to pass Jepsen as well [1].
1. https://www.google.co.uk/amp/s/yokota.blog/2015/09/30/call-m...
Hbase 0.98 (I think?) introduced a feature called "timeline consistency" that allows reads from replica regionservers. This has to be enabled for a table and has to be specified on the query side. If it is, you have the option of falling back to the replica if the primary doesn't respond within a deadline. This may be a good tradeoff if you value availability over consistency.