I think the problem is more with the architects of the applications than with Mongo. You can safely use a non-ACID database for financial applications. You just have to take care of the parts of ACID you need yourself.
It's tricky to get that right, though, so most developers would be much better off picking a database that does it for them.
I've worked on a few large scale financial databases and none of the ones I've worked on use transactions (using Oracle). Most of them are insert only with bi-temporal data: http://en.wikipedia.org/wiki/Bitemporal_Modeling
A simple entry into the field is to imagine that instead of storing a row in which you have a single balance, you would instead have an append-only table in which you store all transactions including their timestamp and auditing info.
The balance would then be calculated as the sum of transactions, and you could modify the query to view a balance in the past by only including transactions before a certain point in time.
A reversal or correction would be an append action, not a modification to existing data. Thus giving you an accurate history of the data.
This is a simple entry point, as bitemporal modelling usually affects the entire datastore and also has to handle potentially massive data and so requires ideas of how to archive old data, and provide performant ways of knowing the current state. There are lots of tricks here, and the sum of those tricks is how bitemporal modelling is achieved.
I've seen the before-and-after at a company that didn't use this sort of modelling and then added it. It was like night and day - suddenly we stopped making embarrassing errors with people's money. Even without really optimizing it for speed, and just using MySQL, and without changing any of the other data model, it works.
not in detail, but imagine: you have code that walks a complex object graph every day to figure out how much money to move. The business rules interact in complicated ways. Do you trust that you'll always get the same value out of that system? Versus "select sum(value)" as a single query...
Is it because it doesn't have transaction integrity?