It seems to me that there are two or three things being conflated here under the "NoSQL" moniker, and Stonebraker isn't helping things.
First, there's the standard relational storage model. We've known for almost 40 years that some kinds of queries are a lot faster if you denormalize so you're not even in 1NF. Occasionally this matters. "Document stores" are a lot better suited to things that aren't in 1NF than relational databases. In theory you could maybe make this problem go away by throwing more hardware at the problem, so that the extra factor of lg N (which might be around 20 or so) goes away.
Second, there's SQL and all of the hassles it comes with, which can be largely papered over by things like SQLAlchemy and Django and the like, but there are still tricky issues like schema migration and incremental rollout.
Third, there's the CAP theorem. ACID requires consistency (the C in ACID and the C in CAP are the same), so you give up either availability or partitionability, and when you give up partitionability you're usually giving up parallelizability as well, which can put a crimp in the "throw hardware at the problem" approach.
It's true that the costs of abandoning standard SQL databases are high. But there are things you can't get any other way. If you need a million queries per second per database server (serving up variable-length lists of structured data), if you need to be able to incrementally roll out a new database schema across your site, or if you need to tolerate network partitions (and latency; a partitioned network is just the limiting case of high latency) without your database becoming unavailable, standard SQL databases aren't going to give you what you need, as far as I know.
As far as I can tell, these are the three sources of "NoSQL": rejecting the relational model as a way to organize on-disk storage, rejecting the SQL DDL as a way to manage change, and rejecting ACID transactions. Interestingly, none of these necessarily implies rejecting SQL as a user-interface language, and indeed FQL is an SQL user interface on top of some very non-SQL-ish systems.
(SQL itself is a terrible language, as Stonebraker will no doubt tell you if you ask, but it's not so terrible as to justify the switching costs.)
First, there's the standard relational storage model. We've known for almost 40 years that some kinds of queries are a lot faster if you denormalize so you're not even in 1NF. Occasionally this matters. "Document stores" are a lot better suited to things that aren't in 1NF than relational databases. In theory you could maybe make this problem go away by throwing more hardware at the problem, so that the extra factor of lg N (which might be around 20 or so) goes away.
Second, there's SQL and all of the hassles it comes with, which can be largely papered over by things like SQLAlchemy and Django and the like, but there are still tricky issues like schema migration and incremental rollout.
Third, there's the CAP theorem. ACID requires consistency (the C in ACID and the C in CAP are the same), so you give up either availability or partitionability, and when you give up partitionability you're usually giving up parallelizability as well, which can put a crimp in the "throw hardware at the problem" approach.
It's true that the costs of abandoning standard SQL databases are high. But there are things you can't get any other way. If you need a million queries per second per database server (serving up variable-length lists of structured data), if you need to be able to incrementally roll out a new database schema across your site, or if you need to tolerate network partitions (and latency; a partitioned network is just the limiting case of high latency) without your database becoming unavailable, standard SQL databases aren't going to give you what you need, as far as I know.
As far as I can tell, these are the three sources of "NoSQL": rejecting the relational model as a way to organize on-disk storage, rejecting the SQL DDL as a way to manage change, and rejecting ACID transactions. Interestingly, none of these necessarily implies rejecting SQL as a user-interface language, and indeed FQL is an SQL user interface on top of some very non-SQL-ish systems.
(SQL itself is a terrible language, as Stonebraker will no doubt tell you if you ask, but it's not so terrible as to justify the switching costs.)