First of all, the (yes, there's only one) Relation Model has nothing to say regarding ACID properties which belong to transaction theory. Of course any real-life implementation will have to deal with those properties but that is another story.
Anyway, although saying that "the ACID aspects that most people associated with the relational model" is correct (most people do the association), saying that "You don't HAVE to throw all the ACID benefits away just because you try a model that is not relational" doesn't really hold unless you say "... just because you try a database management system that is not one of the currently (badly) implemented relational database management systems".
You may think that I'm just being picky, but I'm convinced that most problems lie exactly in a common misunderstanding of basic concepts.
One of the big advantages of the Relational Model is exactly that it doesn't get into the physical implementation details with the consequence that you don't have to change your understanding of the data just because one DMBS implements row-in-pages storage vs. columnar storage vs. any other physical implementation anyone may come up with.
Of course at a certain point the conceptual model (relations) has to come down to a logical model (e.g. ER) and a physical implementation (tables) that deals with concurrent updates (transaction theory).
However, most people simply start singing the inflexibility mantra of the model, which indeed is a problem, but you know what? IMO the truth is that in many (most I would say) cases, it is not an "open-schema" kind of a problem, it's just that people want to build the system without really putting any effort into understanding the data upfront. Which will always bring problems later. If you ever worked in a BI or MDM project, or anything that has to do with data quality, you know exactly what I mean.
To say it in another way: one thing is to struggle to keep up with a changing schema, another one is bothering only about writing code without any will to understand the schema first.
Information has a schema, or meaning, otherwise no one would be able to interact with it. Not bothering too much with a precise definition of the schema only means a higher provability of posing the wrong questions and/or getting wrong answers (paradoxically a lot of practitioners may get correct answers to wrong questions by hammering around with the syntax of the questions but that's also another story...)
And yes! A lot of people are simply re-discovering bad wheels that were dismissed for good reasons. Part of the problem is that they don't want to educate themselves and part is that they feel understanding data as a boring thing compared to coding some stupid algorithm to support some already known structure.
This is one side of the SQL vs. NoSQL debate (schema vs. no schema), the other one boils down to the ACID vs. CAP vs. Nothing approach but I would say that a similar reasoning applies. It's simply easier to go down the "eventual consistency" route than fully supporting ACID properties.
It's perfectly fine to have Facebook's photos partitioned because if someone can't see the latest wild party photos, he will simply move on (and maybe check later). It's not the same thing with a lot of other scenarios though.
So in the end I sort of agree with you, it all boils down to really understanding the problem at hand and choosing the right technology. However, this is not what I see. I don't see the "understanding" part. But I see a lot of uneducated people fiddling around with the latest technologies du-jour that are really vintage fashion.