What was very interesting was bullshitting with somebody who knew a good chunk from DataStax, and realizing that the use cases for Cassandra actually do edge out pretty far into traditional business territory. It's something that you could actually envision replacing mainframes and whatnot in many cases, even for relatively mundane line-of-business applications.

I think they can do it, but I dont think the ROI would cover the investment to change hardware and software for a system that currently works. Unless you are up against an hard EOL for your 'traditional' install I think it would be a large gamble to change. Im speaking for 'traditional' enterprisey install bases only though.

This is true. Most companies either start using Cassandra when their existing database infrastructure is struggling with a particular workload or they're planning a new feature that would be prohibitively difficult or expensive with an RDBMS.

The one exception to this might be a need for higher availability, especially if expanding to multiple datacenters is part of the plan.

Can you elaborate on some specific use cases?

Why are update statements actually inserts? Am I missing something ( besides eventually consistency by design ) or are they trying to trick me?

Because they don't do a read before insert/update/delete, so random inserts don't do random reads/io, but create new versions.

They aren't trying to trick you. Bigtable,hypertable,hbase (i think even tokudb/mx) work the same.