Relational databases are always are good solution; however, they are not always the best solution for the problem at hand. The real problem is that once someone has their head wired to an RDBMS, it's often impossible to get them to even consider another solution. It becomes their golden hammer.
The articles main point, that "SQL Databases Are An Overapplied Solution", is absolutely correct.
That is a blatant myth. Joins are not slow.
The bill of goods that RDBM's sell is that data integrity trumps all else. The reality is that is doesn't. Data can be cleaned and integrity maintained by background processes if the performance you get is more important to you than absolute up to the second data integrity. There are lots of cases where available data is far more important than up to the second accurate data.
Eventual consistency is more than good enough for many many things common web applications do. In many cases it's perfectly fine that the web app is looking at 4 or 5 hour old data, it just doesn't matter, what matters is that it can look at it in milliseconds without having to rebuild it on every query.
In other words, it's premature optimization.
Most people aren't building banks, for most apps data corruption is not the big concern RDBMS fans make it out to be.
Now older versions of MySQL, like 3.23, are still in use (unfortunately) and pretty crappy but it was released over 8 years ago. Most of these performance myths about MySQL are outdated.
Are there any improvements in this area, or is it still just the same old, same old?
Of course they aren't the answer to every problem, and I think unstructured or semi-structured data (such as HTML pages or text data with entity tags) is a good case for storing things in a more document oriented system.