I don't think you understand the niche that NoSQL databases are trying to fill.
The more interesting aspect of all of this 'NoSQL' movement is how they believe that if they achieve some speed improvement against some relational databases, how that makes them so much better.
It's not a black and white, panacea-type situation. Relational databases are good at some things, non-relational databases are good at others. Where non-relational databases are better is at solving very specific problems, many of which happen to map directly to the needs of web developers.
A Viper is a fun car to take you to and from work, but it's probably not the best to shuttle around a little league baseball team--that's what minivans are for. (Whether the Viper is the relational or non-relational database in the analogy is up to you.)
I teach a course titled Advanced Database Concepts, so I'll give you the same example I give my students: blogs. It's the sort of canonical example--I didn't make it up.
To show a blog's home page, you need a list of recent posts. Each post is probably associated with a category, maybe some tags, and and author. Just to get that data, you're looking at joining 3 tables: Posts, Categories, and Users. What if you want a comment count? That's another join, and the query just got hairier--do you do a simple aggregation (join then group), or do you see that might be inefficient and so transform it into a harder-to-read-but-more-efficient subquery? That might even involve a fifth join, if you have registered user accounts and avatars for your commenters.
All of which is fine and good until you're running LiveJournal or WordPress.com and you have millions of bloggers generating hundreds of millions of posts and who knows how many comments. With beefy machines and proper indexes you're probably okay ... but I wouldn't want to be the DBA who had to tell management that a new column needed to be added to any of those tables.
Enter NoSQL/non-relational databases: why not fetch everything with just one query? (I'd show you some JSON, as that's what many of the NoSQL databases speak, but the /. filter considers it too much junk.) You put your comments in the same document as your posts, and the replies to those comments in child arrays, and the user info right inside the comments. If your users can't change their username, this isn't a bad solution. There are other tricks, but the point is that you reduce everything down to a single denormalized query.
This design makes it trivially easy to build data-driven web pages, as effectively every web language has a JSON deserializer. No ORM impedence mismatch, and you get horizontal scalability pretty much for free.
If you don't really need a database to run your 'website', then who cares if you use flat files or an in memory hashmap for all your data needs?
Because it's still a database, even if it's non-relational. You're still doing inserts and updates and deletes, you just get a nice hunk of denormalized clay to play with instead of the normalized rigidity of Tinker Toys.
I think that relational databases are good at what they do and that many projects may not need them, but if you do need them on the back end, you will end up with them on the back end.
But that's the point I think you're missing: until relatively recently, relational databases were the only game in town. Relational databases are ubiquitous because they solved the problems of the 60s-90s. They aren't going anywhere, as those types of problems (financial, transactional, etc) aren't going anywhere. But now we have a relatively new class of problems (graphs, etc) that need to be nailed down just as thoroughly. Many web applications are straining to fit within the relational model, and this explosion of NoSQL software is because people are realizing that all that straining can't be good for them.
Is there really a huge issue with rdbms speeds?
Others may disagree with me, but I make the point that it's not the speed that is the problem--it's the scalability. Sure, you can keep throwing memory and horsepower at the problem and hope that covers it. Partitioning data across database servers is a tough problem, with no perfect solutions. But why keep fighting on the bleeding edge of technology like that? NoSQL databases are designed to be easily horizontally scalable from the start (in many cases you wouldn't believe how easy it is), even though they may lack the huge feature set of an Oracle or Teradata solution.
But just to reiterate: non-relational databases aren't a panacea, either. Each type of database has it good points and bad points. Each solves a set of problems, some of which overlap and some don't. The reason you should care is because now you have more options--you're not stuck trying to wedge your system into a relational model if you don't want to. And isn't /. all about freedom of choice?