A lot of the entities we deal with in web apps are complex, multi-table structures when stored in a relational database. Think about blog articles (tables: article, author, tag, comment), user profiles (tables: user, friends, follower, interests, etc.), photos, tweets, ads, and such. The beauty of something like MongoDB is that you can store all the data as one "record" in a collection. You can also retrieve it with a simple query. These "records" are structured as something like JSON, so you can just take the data structures you're using in your app's code (particularly Python or JavaScript), and store it as-is with no conversion.
Compare this to an RDBMS-based web app, where to display a blog article for example you'd need to make multiple queries of different tables: first the "article" table to get the text, then the "author" table, then all the comments, tags, images, or whatever. The NoSQL way is much easier to code for this sort of thing. The lack of ACID doesn't matter so much because these kinds of data are usually written just once, read many times, edited rarely, so there are few opportunities for inconsistencies to creep in.
>for example you'd need to make multiple queries of different tables: first the "article" table to get the text, then the "author" table, then all the comments, tags, images, or whatever
You're just outsourcing the impedance mismatch problem to the database. Yes, we can write complex SQL (and I've written some really complex SQL) to combine multitudes of entities together and generate a result. NoSQL databases eliminate this.
Where it becomes extremely impactful is when a database is distributed or sharded across a cluster. If the various tables (article, author, comment) are stored on different servers, it takes time for the database to reassemble them. Moreover, modern web apps often have content that's written once, read many times: blog posts, photo posts, status messages, news articles, advertisements, catalog listings, etc. Why re-do that work of assembling the content every time people want to look at it? When documents are rarely or never edited, the relational model's defenses against "anomalies" become less relevant. Far better to use a document store like MongoDB, which stores a piece of content as an integrated whole at a single place in the database.
Compare this to an RDBMS-based web app, where to display a blog article for example you'd need to make multiple queries of different tables: first the "article" table to get the text, then the "author" table, then all the comments, tags, images, or whatever. The NoSQL way is much easier to code for this sort of thing. The lack of ACID doesn't matter so much because these kinds of data are usually written just once, read many times, edited rarely, so there are few opportunities for inconsistencies to creep in.