Some projects may never need ad hoc queries because by the time they hit scale enough that they need such reporting they might go directly to BI tools (Cubes, Elastic Search, et al) or "Big Data" tools (Hadoop, Big Query, et al) without needing an intermediate SQL step.
The same is true with transactions and consistency models. Some projects may never have a need for anything stronger than eventual consistency and may never need more complicated transactions beyond the scope of an individual JSON document. Even then, there are chunky hybrid solutions with good options for choosing a different ACID plan or locking mechanics or transaction capabilities, and just because most "NoSQL" databases are in the corner of eventually consistent and transactions only at the individual document level does not mean that all are (there are definitely exceptions out there).
Again, there will always be projects and business domains on both sides of this "data spectrum". There's no wrong answer, just what's right for your specific project or business domain.
I think WorldMaker hit it on the head: do you plan your queries up front, or your data?
From the beginning, I saw NoSQL as being great for prototyping or MVP. But the reality of our industry is that you very rarely get to bang something out overnight, then rewrite it the "right way". Your prototype or MVP more often than not becomes the foundation of your stable, mature releases.