Key-value stores: you can only query by the key. So, you can say "give me article 7", but you can't say "give me articles by author 5". That's a huge limitation and doesn't allow you to make many applications. Now, key-value stores definitely have their place. For some purposes, they allow you to get better speed and scalability. However, I wouldn't want to be running my whole site off it alone.
Column based databases: these are wonderful for data warehousing and map-reduce like operations. However, that comes at a cost, namely random access. If your data is stored as 1,John;2,Adam;3,Samantha;4,Amanda you're easily able to grab all the columns for a person. However, if it's stored (as in a column database) as 1,2,3,4;John,Adam,Samantha,Amanda it becomes difficult to reconstitute a random row since the data isn't stored together. And what are you likely to be doing with your web application? Sure, I might want to analyze all the values in a column sometimes, but more often than not, I'm going to want to get the data for a row.
This isn't the end of the RDBMS. It's just more useful and a better tool for a lot of what we do. And we don't just have to use one tool. We can easily use key-value stores to supplement an RDBMS where the key-value store is a better tool - like caching. There's a reason that RDBMS systems are so widely used on high-profile sites including to power Facebook, Wikipedia, and WordPress.com (the 4th, 7th, and 20th most visited sites on the web worldwide). An RDBMS isn't the only tool they use, but it's good at data storage that needs to be accessed randomly. Sure, it needs to be supplemented by other techniques when you get to high volume so that operations that don't need an RDBMS don't use it, but there's a reason that Flickr, Craigslist, Twitter, Digg, LinkedIn, del.icio.us, LiveJournal, StumbleUpon, and many more of the largest sites use them.