Specifically is there some risk that data can be lost? I'm looking at running an intensive transaction processing system where it is critical that nothing be lost. Are there any examples of NoSQL being used in mission critical applications such as banking transaction processing?
Without being flippant, the absence of ACID means you get no guarantees of atomicity, consistency, isolation, or durability.
Without atomicity, you get no guarantee that multiple actions that must either succeed or fail together do so. For instance, if your transactions require you to debit one account and credit another in one go, in the absence of atomic transactions, you either have to roll your own solution, or accept that it's possible for you to debit one account, without making the corresponding credit.
Without consistency, there's no guarantee that "side effects" of your transactions work - in relational databases, that's things like the firing of a trigger, or the cascading of a foreign key relationship. So, if you need some kind of auto-incrementing unique identifier for your transaction, there's no guarantee that you will get one.
WIthout isolation, there's no way to guarantee that two processes don't affect the data at the same time. For instance, one process might be incrementing the value of a field, and a second one might be decrementing it - who wins?
Without durability, hardware failure could leave the database in a different state than you expect - for instance, you may believe that a change was written to the data store, but it was queued in some internal memory buffer, and disappear into thin air if there's a power failure.
It's probably possible to build a solution on NoSQL which works around the absence of ACID compliance, but the level of effort would be huge, and you almost certainly won't do as good a job as the guys who write relational databases....