For rapid development, there are a wealth of tools that will just work on SQL databases. No special query language to learn. Jeez, none at all if you use one of the nice ORMs and magic query writing they provide (which was the point of this article). You can even drag and drop your way to a semi-decent app if you know that toolset.
On top of that, you get well-known consistency, transactional updates, and so on. Stuff most developers are used to. So, there's plenty of reasons for picking a traditional SQL database, especially when starting.
Even more so, you don't need to throw SQL away (which is a nice declarative query language) in search of performance. For instance, look at VoltDB/HStore for an example of a SQL-based, table based RDBMS that provides ACID, high performance and linear scaleout. (Granted, with some tradeoffs - it's not for running reports off of, for instance.) On the non-OLTP side, look for massively parallel databases, which still allow SQL while providing amazing scaleout analysis performance. (Downside is that those analysis databases are very expensive; I'm unaware of any cheap or opensource alternative that still uses SQL, except perhaps Pig, but it doesn't really compare, performance-wise.)
On top of that, you get well-known consistency, transactional updates, and so on. Stuff most developers are used to. So, there's plenty of reasons for picking a traditional SQL database, especially when starting.
Even more so, you don't need to throw SQL away (which is a nice declarative query language) in search of performance. For instance, look at VoltDB/HStore for an example of a SQL-based, table based RDBMS that provides ACID, high performance and linear scaleout. (Granted, with some tradeoffs - it's not for running reports off of, for instance.) On the non-OLTP side, look for massively parallel databases, which still allow SQL while providing amazing scaleout analysis performance. (Downside is that those analysis databases are very expensive; I'm unaware of any cheap or opensource alternative that still uses SQL, except perhaps Pig, but it doesn't really compare, performance-wise.)