What the other answers seem to be missing is that the generally-applicable alternative to ACID isn't "nothing", it's something called eventual consistency (sometimes nicknamed BASE).
When people say they need ACID semantics, often what they really mean, at least from a domain/business requirements point of view, is simply data integrity. They want to make sure that data doesn't get lost or corrupted. Many NoSQL databases still provide this guarantee, they just provide it in a different way and on their own terms.
It's certainly possible to use a NoSQL or BASE database as an unsafe alternative to a SQL or ACID database, if you treat it as simply a "non-ACID database". Making an informed decision means you understand what has to be done at the application level to compensate for the lack of coarse-grained transactions and play to the strengths of EC. Some common techniques are:
Optimistic concurrency, which is already used to minimize locking in a transactional environment.
Idempotence of operations, such that if a long-running operation fails halfway through, it can simply be retried again and again until it succeeds.
Long-running transaction techniques using compensating transactions, often called sagas in distributed systems, where multiple independent transactions are grouped by some correlation identifier and the state of the entire operation is tracked independently. Often these actually use ACID semantics for the saga state itself, but that is much more lightweight than a two-phase commit.
In point of fact, if you spend much time working on distributed systems - even those with ACID semantics available at each of the individual subsystems - you'll find a lot of these same techniques used to manage cross-system operations, because without them you just obliterate performance (think BizTalk and BPEL).
Once you've had some experience with it, you'll realize that it actually makes a lot of sense and is often easier than trying to apply ACID semantics. Computing processes are just models for real-life processes, and real-life processes can sometimes fail in mid-stream. You booked a flight but suddenly you can't go anymore. What do you do? You cancel. Maybe you get your money back, maybe you don't, or maybe it's something in between - those are your business rules. Or maybe you started your booking but got distracted or sidetracked or your power went out, and now your session's timed out. What do you do? Simple, you start over.
To really address the question head-on, I'd answer thusly:
You need ACID semantics when:
You can reasonably expect to have multiple users or processes working on the same data at the same time.
The order in which transactions appear is extremely important;
You cannot ever tolerate stale data being displayed to the user.
There is a significant and/or direct cost to incomplete transactions (e.g. a financial system where unbalanced totals can have grave consequences).
On the other hand, you don't need ACID semantics if:
Users only tend to perform updates on their own private data, or don't perform updates at all (just append).
There is no implicit (business-defined) ordering of transactions. For example, if two customers are competing for the last item in stock, it really doesn't matter to you who actually gets it.
Users will tend to be on the same screen for seconds or minutes at a time, and are therefore going to be looking at stale data anyway (this actually describes most applications).
You have the ability to simply abandon incomplete transactions; there is no negative impact of having them sitting around in the database temporarily or in some cases permanently.
The bottom line is that very few applications truly require ACID semantics everywhere. However, many applications will require them somewhere - often in isolated pockets like saga state or message queues.
Next time you're designing a new application or feature, try giving some thought to whether or not it might be possible to model an atomic/isolated "transaction" as an asynchronous "chain of events" with a little extra state to tie them all together. In some cases the answer will be no, but you might be surprised at how often the answer is yes.
