I take your points. Here's the thing: if ACID is an aspect of developer tools and not a user experiences, and if ACID tools are the default, and if (as anyone who has held a checking account in the U.S. would surely agree) user-experience failures analogous to ACID violations occur regularly, isn't that evidence that we should continue to question what value we actually get from basing our systems on ACID/relational data stores?
Asking what value a particular app gets from an ACID store vs a non-ACID store as part of a comprehensive analysis of two competing technologies is a GOOD THING.
As for banks, exchanges, credit cards, packages, etc:
When non-trivial sums of money are changing hands, ACID stores offer tremendous benefits as a building block in a larger system.
Yes, things go wrong. Even given ACID building blocks, building huge banking systems is hard. Forcing bank developers to worry about consistency not just between systems, but also within systems isn't going to make that job easier.
