The page linked goes into more detail, but among other things, Compare and Set operations are only concerning one data element at a time - meaning you cannot do Atomic updates to multiple keys. The ability to do multiple key updates atomically makes it possible to build higher level abstractions by reliably combining data from multiple keys under concurrent workloads.

Basically, transactions that can span an arbitrary number and set of keys are what makes it possible to build rich data models from simple ones. SQL databases are a perfect example of this - most use a simple transactional data store on the bottom to store complex relational data structures. A single SQL operation may require many key-level updates - but this is OK if you can wrap them all in ACID transactions.Without ACID transactions you can't guarantee data consistency because keys will be getting updated at different times, allowing for a mix of old and new values.

It's a shame to see vendors trying to change the meaning of ACID to fit the limitations of their databases. It means more confusion and bad decisions in a market that needs clarity and honesty for people to make the right decisions for their applications.