Rapid iteration comes to mind (as a result of its lack of schemas). It's also great if your objects are JSON documents, and as such it's particularly suited for uses such as a backend to Backbone.
Those are two areas in particular where I would first look to Mongo.
Don't lie to yourself, it has schemas. They are just implicit. Want to write JavaScript migration scripts for changing the Schema? I sure don't. But that is not even the begining to describe how broken mongodb design is. getLastError as a way to do write confirmation?
You can call them whatever you want, but I don't need to write any migration scripts when I change the schema. Writing a migration script MIGHT be a good idea, depending on my setup, but I definitely don't NEED to.
I don't really know what you mean about the design being "broken", unless you mean that it's "different", in which case I would agree.
As for write confirmation, you have flexibility in that regard. You don't need to be checking getLastError for write confirmation[0], though if you wanted to use a broken pattern, you could.
The first reason sounds a lot like 'hacking things out.' That is wonderful in the early stages of development, but 'production' doesn't just getting the app live quickly. With an ORM, let's take Rails as an example, migrations make schema changes extremely fast.
As for JSON, Postgres has first class support for JSON data field types.
Those are two areas in particular where I would first look to Mongo.