"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.