I've looked at MongoDB/norm (but want a general document-oriented store answer). It seems really nice to work with and I'm interested in knowing when it should be used instead of RDBMS+ORM?
What should i use for for instance:
(I posted another more general question but it got a splendid answer that might be interesting for others, hence the new question)
All of the examples you mentioned can be built using a document store. Whether you should use it, depends on the exact requirements.
If you're dealing with a social community that supports money transactions, you really should use an RDBMS to handle these transactions. You simply cannot afford to have inconsistent data in this area.
If your application doesn't have very stringent requirements in terms of data consistency, you can consider using a document database. It has several advantages over an RDBMS. For example, if you're using domain-driven design to build your application, you'll find that aggregate roots can be naturally stored as a single document. This will result in very little data fragmentation within entities, giving you better performance when you're sharding your data across multiple nodes.
Some drivers, including NoRM for MongoDB, support type discriminators. These allow you to persist and rehydrate multiple subclasses using very little configuration. For example, if your application supports multiple types of home addresses, the driver will take care of handling the different address subtypes. You can also add new subtypes and the driver will automatically handle these as well. See this article for a detailed example.
The above wouldn't be possible without the biggest advantage of document-oriented stores over SQL databases: schema-less data. If you're dealing with user-defined data, document databases are the way to go. For example, if you allow users to upload files and freely tag them with whatever data they want, you can easily store these tags as plain key-value pairs, or even nested key-value structures for categorized tagging.