Not sure I understand the MongoDB hate here. Migrations and denomalization is not somthing you have to deal with in MongoDB.
MongoDB can store data in a schemaless fashion, however, chances are your application has a data model (schema).
Sure, you can avoid migrations and just tack on more and more backwards compatibility for old data layouts. But performance suffers, and chances are that code quality and correctness suffer too.
"Denormalization is not somthing you have to deal with in MongoDB."
What do you mean exactly? If you have a piece of data, lets say an address, that exists in more than one place as is the mongodb way, you will absolutely have to deal with the fact that you need to now update that data multiple times. So denormalization is very mcuh some you have to deal with in Mongodb.
Just like in a relational database, denormalization has serious consequences and should only be used when the need for performance outweighs the risks of having much more complex code and hence potentially many more hard-to-debug errors.
Something that I've come to believe is that developers don't spend nearly enough time gathering process data that would let them make explicit forecasts (even order of magnitude). Once your team has aligned on those forecasts, a bunch of design debates just fall away.
If you really want to have fun, start a prediction market - though that might end up creating its own set of debates :)
Yes, you still have to deal with migrations. When you change the data model, you have to compensate, either with modifying the underlying data or by compensating for it in code.
"denormalization" is really just structuring your data model for best performance for your underlying data store and code algorithms. And you most certainly have to do this in mongodb as well.
The great thing about using migrations is you pay this price once, at upgrade time. Not in yoru code on every query to the data layer.