I too have left ORM-land (in C#). I found that the first two of your points are absolutely true. I've also found that if you know how to code a clean, well-factored data access layer then it doesn't necessarily even take a whole lot longer than wiring up an ORM does for non-trivial cases.

I also found that using the ORM was having a detrimental impact on performance and scalability in a subtle way that had nothing to do with the ORM itself: It's that I got used to operating so far from the database layer that I wasn't really aware of what was going on down there. Last time I did a conversion of a project away from ORM, the number of forehead-slapping moments when I noticed a simple way to improve an operation's performance by at least one order of magnitude was downright embarrassing.

That said, that's where I depart on the third point. I've also moved to using stored procedures for everything. I don't know if the situation is quite the same for MySQL users, but in Microsoft-land the amount of tooling SQL Server and SQL Server Management Studio provide to help with managing, analyzing, and refactoring SQL code is really pretty impressive. . . and if you divorce your SQL code from its native environment by demoting it to being nothing more than string resources that are subservient to the application code, you're letting go of a lot of those tools. Or at the very least, creating a lot of unnecessary friction when it comes to getting at them.

However, as a RAD kit I think ORMs are fantastic. They can, as the article highlights, do a lot to protect someone with limited skills in database work from getting themselves into trouble. But they're still just a RAD kit, and like any RAD kit they have their limitations.