> One argument is that a schema-less approach solves the issue of dealing with schema evolution.
That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.
That's a discipline issue. Nothing stops people from writing their apps to do data migration on update. That is, have their model classes fill in any missing attributes with default values etc. before saving it back. The difference is that you can do it selectively.
Nothing stops people from creating retarded schemas for RDBMS's either.
Data migration requires a list of what the data looks like as of each version. Doing that by hand is just as much work as maintaining a schema, with the disadvantage that you'll find out the hard way, too late, whether it reflects reality.
That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.