They've probably tuned Cassandra to favor write performance, accept a write as valid before it has actually replicated everywhere. The cost is that when reading the data, you now need to do more work to verify you got the latest value.
This is extremely common and is normally caused by an optimization for streaming writes that leaves data relatively disorganized, in which case you need to perform numerous reads to find data which only required a single write to store.
In the same topic, dunno if it applies to cassandra.
I've seen some databases work in "append only" mode. They write new data to the end of the file. They never erase existing data.
It's generally a very efficient write patterns (even on good old spinning drives) and it allows to always write in batch.
On the opposite, read are expensive, they require to "find" stuff from various places and read it and verify it and [if configured] repeat on multi nodes to compare the values.
Cassandra has an append-only log file during operation but unlike a RDBMS it's not just used for transaction replay, so you're half write. Cassandra periodically compacts the log and writes SSTable's to disk, but newer data and tombstones are stored in the log for a while which as you surmised does have a performance hit.
Performance hit is not from the log though, but from having non-reading-writes (and ttls). So you have to look other versions too on disk for latest value.
I think newer data and tombstones would stay for a while in sstables, not in the log.
Why is read 10x more expensive than writes?