Being the author of the report, a vulnerability researcher, and having been in the industry for years I too think your post misses the point. The article wasn't written for someone who knows the ins and outs of properly securing an environment, it was written for the corporate IT professional or corporate IT security professional who gets thrown into a meeting and someone mentioned the new app they are deploying uses "NoSQL" and they don't know what that means or how they can even start securing it.
While the editors may have sensationalized the title, the key here is that the majority of the users of NoSQL databases are not security researchers or even developers that understand proper defense in depth. Most are using these "database technologies" to solve a specific problem or because they are "cool" so when they go from dev to production, very few controls are implemented anywhere in the stack (network, OS, or app).
Furthermore, if the solution to securing a NoSQL DB is to "secure everything around it" (e.g, the references in the posts to hardening the OS, Network, segmenation, etc) then I can tell you it isn't happening and the deployers of NoSQL don't know that.
The financial institutions that are using NoSQL, that I have assessed, aren't using commercial versions mostly because a developer throws something together, proves it works, and moves it into production rather quickly. I think they will move to commercial versions though as more support is needed.
I don't have an axe to grind, and if you look at my previous database security reports I don't think the big SQL DBs are great either BUT they do provide more options for controls to be put in place at the database level. Of course the rest of the stack should be secured too(duh) but when it comes to defense in depth you want to have as granular controls as possible as close to the data as possible.
I did not make the claim you shouldn't use these technologies, rather I make the claim you can't assume these technologies support the same controls as other relational databases have and call it a day. You have to be much more creative to properly control and audit access.
Lastly, it is difficult to provide actionable technical advice in a article format such as that used by InformationWeek because of the wide variety of readers. Rather, we make recommendations that readers can use to do additional research and find the proper answers which is what we did provide in the actual research report (which is longer and more detailed than the articles).
Oh, and I think Tom had the right idea. Can you explain your firewall and SSL comments? Also, xp_cmdshell as been disabled by default since SQL 2005, so that isn't valid example of "in-secure by default" for a new deployment (even though an attacker can re-enable it if they are 'sa'). If you are deploying SQL 2000 into an environment in 2012 you have other issues)