I'm challenging the idea that if you're just using an ORM for persisting objects you're probably doing it wrong.
For the vast set of programming problems having that user table that's relationally linked to a person table that's relationally linked to a company table that's relationally linked to, etc. gives you far more flexibility than having to start dealing with getting objects out of a key-value pair store and manually piecing together complex relationships just to add a simple page to the client's admin page to say how many people have setup their account properly (as a random real-world example where the admin emails their staff and they setup their own user details).
Once you get past the basic CRUD of a problem and start having to use the data for functionality, basically past anything more than a toy program, the relational model through an ORM is going to be much simpler than a NoSQL solution.
I just don't get how this statement makes sense:
ORM is great when a database is being used as a simple program data persistence layer, but if you limit yourself to that then you might as well use a NoSQL solution
I wouldn't because as soon as you start adding fairly simple functionality the NoSQL solution would rapidly become a nightmare. To me NoSQL would be the go to solution if I had a few very basic data structures that I had to do a lot of work on, not the opposite as dmethvin suggests, lots of different objects with simple operations.
In concrete examples, Google, NoSQL, Instagram, probably NoSQL, something like Freckle (Time Tracking), SQL, Salesforce, SQL all the way.
But as I said I've not had a project or personal project yet where I've gone 'Aha, now is the time! NoSQL here I come!' so push back if I'm doing it wrong!