From a development standpoint, I don't quite understand the advantages of NoSQL over SQL. I get that you don't have to have a rigidly defined table structure, and that your data structure can change when your application changes, but I guess I'm one of those curmudgeons that prefers rigidity over permissiveness. I like that I have to think hard about my table structure and models before and as I code. I also rarely feel bogged down by SQL, although I've been using it for over a decade, so that helps.
As for scalability, as this post shows, I think the best thing to come out of NoSQL is the race for greater scalability it has and will continue to inspire in SQL solutions.
"NoSQL" has come to symbolize a number of different things, depending on who you're talking to and when. I've seen all combinations of one or more of the following:
1. The rejection of what some see as an overly complicated and inflexible query language in favor of map-reduce phases or other application-side querying/processing.
2. The rejection of serialized transactions in favor of something like eventual consistency, often with application-specified conflict resolution.
3. Or it could be a rejection of the relational model (especially as it is popularly implemented) in favor of key-value, graph, document, column-oriented, etc. models.
If I read you and the authors right, I think you're thinking more along the lines of 3 and the authors are focussing more on 2.
I think both "sides" are just starting to come to grips with the idea that these design choices can be orthogonal (a relational DB without SQL? an eventually consistent SQL DB? a graph DB with 2-phase commit?) and choosing to reject one part of "the old way" doesn't mean you have to reject all of it. The upshot is, we're going to have a lot more tools to choose from for our own unique problems.
So, I'd say: don't worry about feeling like a curmudgeon! Rigidity will have its place in the beautiful gleaming pluralistic future of datastores that the SQL vs. NoSQL "debate" is building the road towards.
There are some times when the standard normal form is a real pain, for example, and your data fits better as a document or a simple key-value. I mentioned one such instance for me here: http://news.ycombinator.com/item?id=1637903
As for scalability, as this post shows, I think the best thing to come out of NoSQL is the race for greater scalability it has and will continue to inspire in SQL solutions.