Jeremy Zawodny from Craigslist explained why it helped them a lot for Craigslist archives database, where an alter table could take up to 24 hours: http://www.10gen.com/presentations/mongosf2011/craigslist
NoSQL ~= NoMySQL
PostgreSQL supports transactional schema modifications. fast adding and removing of columns, and lockless index creation. So in simple cases upgrading the schema is trivial. For complicated cases it can be a mess, but my guess is that that applies to any database.
Also don't forget that MongoDB can have arrays and sets as a "column" type. Which if you tried to replicate in RDBMS would mean a multi-table migration.
Which is not by itself an advantage. You still need to write the code which does the schema change if you for example rename a field.
> Also don't forget that MongoDB can have arrays and sets as a "column" type. Which if you tried to replicate in RDBMS would mean a multi-table migration.
So can PostgreSQL. The sets are not as general as in MongoDB though since they can only store strings.
With RDBMS. I have to write an update SQL script, rollback SQL script, run it against my dev environment, ensure it is applied through test environments and hope the DBA doesn't forgot to run it in production (it happens).
Having written more than one mechanism to automate schema upgrades in remote deployments, and numerous migration scripts, I know it is an extra step in the development process, but I have not considered it an onerous one.