The answer to this question really depends on the project you are working on.
If you think you don't need ACID even though your data is very important to you then I recommend you to read some great Jepsen articles series by Kyle Kingsbury[1][2] showing how popular distributed systems lose data on during network partition. If you don't believe it you can download the tests and run them yourself. Overall it's a very good read especially since he also tries to explain why they fail.
[1] https://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-a...
[1] Unfortunately, searching hasn't turned up the comment... yet.
* A - you have the ability to not use transactions (technically it still implicitly uses transactions per statement, but that's kind of expected behavior of the NoSQL databases).
* C - simply don't use rules such as constraints, triggers etc.
* I - reduce isolation level of the transaction. Postgres due to its design doesn't allow you to have dirty reads (ability to read from concurrent uncommitted transaction)
* D - there are several settings (e.g. disable sync, wal etc, create an unlogged table) which increase performance at the cost of potentially losing your data. You will also reduce it when you use asynchronous replication.
The ACID is a feature that is generally desired when your data is important to you and you also want to be certain that the data is always consistent at any point in time. It's quite hard to implement it right, so it should not be treated like a bug.
Generally you should think of RDBMS as general purpose databases that have strong consistency guarantees, and the NoSQL as a specialized databases which no longer provide ACID guarantees in order to tackle specific domain.
There are also NoSQL databases which try to be general purpose, such as MongoDB. Those are joke. MongoDB for example currently not only is much slower than Postgres[1] it also doesn't horizontally scale[2] on top of that you don't even have ACID guarantees so you're getting the worst out of both worlds.
[1] http://www.enterprisedb.com/postgres-plus-edb-blog/marc-lins...
[2] https://www.datastax.com/wp-content/uploads/2013/02/WP-Bench...
I've seen far, far more cases of document databases being used in situations that are entirely inappropriate, than in situations where they are ideally suited.
I'd argue that the situations in which it's a good choice to use a document database are pretty rare, and that you're almost always better off using a bog-standard relational database.
I think the author of the post has made a good point, that many seem to forget - it is always a trade-off whichever tool you use.
What does "realtime" have to do with the datastore?
Whereas with SQL you have the option of using cache layers (which you could say is NoSQL anyway), message queues, naive timely polling and log monitoring.
With NoSQL the solutions are just simpler. For example Firebase has a tutorial for creating a real-time chat [1] - it takes 5 minutes.