In my opinion, the major reason to leave behind ACID databases is if you have reached the point where they can't scale up any more. If you have reached this point, you're probably a company with 20+ developers. There might also be very specific use cases where specialised databases are useful, such as a search index.
ACID gives you a lot of nice guarantees and it's silly to give it up if you have the choice.
As for MongoDB in particular, I would never use it for anything. It doesn't seem to do anything particularly well. There are better specialist 'NoSQL' databases that have actual benefits to fit your problem.
Are you bigger than Wikipedia? Wikipedia's technology is quite conventional, yet they're the 6th busiest site by traffic. It's MariaDB with memcache, basically. If you're a mostly-read operation, you can have lots of slave databases and caches as you scale. By the time you need exotic database technology for a web site, you probably have hundreds or thousands of employees.
Most of the real use cases for NoSQL involve systems where writes dominate. These are data collection systems where, later, someone searches the data. Surveillance, geophysical data, that sort of thing.
Read-your-writes consistency is not preserved with read slaves which can show up in lots of ways. Create a document, get redirected to the URL for the document, document is missing.
That's sovable in numerous other, simpler ways than exotic DBs. For example, a project I worked on for a few years had a read-your-write issue. Our solution was to keep track of the timestamp of the last write each user made in an encrypted cookie. Then, we used the timestamp to control which slave (or even possibly the master) was used for queries. The result was that a user would always see their own writes, even if other users lagged a couple seconds behind.
Hacker News has that problem. Post a comment, refresh the page, and the comment may not be up yet. If you have cache front ends, it's expensive to avoid. You could probably do something with Javascript where the page checks if the cache has changed after N seconds, where N is the cache expiration time, and reloads the page if necessary. Then you're eventually consistent.
Frankly, I cannot understand to write queries that verbose and complex when SQL looks clear and concise.
If I'm missing on how good RethinkDB is, I will gladly like to know.
One part SQL is notorious for is you don't know where it could fail until you send the whole query and receive the error unlike these NoSQL where operations can happen progressively.
While ORM can sort of mimic that behavior, I don't like that it hides SQL which makes crappy SQL alot easier to write and harder to debug.
It depends on the use case you want it for. Unless you're at massive scale, I don't think non-ACID databases are ever really appropriate as a general purpose store.
There are niches though. Graph databases, search indexes, databases for logging, time series databases, mapreduce, etc.
What is a good database for massive-scale logging and task queuing? I am thinking of experimenting with RethinkDB or Redis, and would love to hear your thoughts.
Massive-scale (searchable?) logging is done with elastic-search. Redis is ok for task-queueing but is in-memory. ~best in that case (most features) would be rabbitmq (based on "python celery") though it ~should be enough in your usecase
hell, you can even use your favorite (postgresql) rdbms to queue tasks
ACID gives you a lot of nice guarantees and it's silly to give it up if you have the choice.
As for MongoDB in particular, I would never use it for anything. It doesn't seem to do anything particularly well. There are better specialist 'NoSQL' databases that have actual benefits to fit your problem.