If you have data structures that are not clearly defined at the time when you make the system. I tend to keep user settings in nosql, for example. Another example was a system where the users needed to be able to add fields at runtime - very painful in an RDBMS and a breeze in NoSQL.
If your model structure is largely centered around one or few model objects and most relationships are actually child objects of the main model objects. In this case you will find that you will have fairly little need for actual joins. I found that contact management system can be implemented quite nicely in nosql for example. A person can have multiple addresses, phones and e-mails. Instead of putting them each into a separate table, they all become part of the same model and you have one person object.
If you want to benefit from clustering your data across multiple servers rather than having one monolithic server, which is commonly required by RDBMS.
Caching. Even if you want to stick with a RDBMS as your main database, it can be useful to use a NoSQL database for caching query results or keeping data, such as counters.
Storing documents. If you want to store coherent documents, in a database some of the NoSQL databases (such as MongoDB) are actually specialized in storing those.
What about joins?
Honestly, the no join thing sounded quite scary to me too in the beginning. But the trick is to stop thinking in SQL. You have to actually think with the object you have in memory when you are running your application. These should more or less just be saved into the NoSQL database as they area.
Because you can store your full object graph, with child objects, most of the need for joins is eliminated. And if you find you need one, you will have to bite the bullet and fetch both objects and join in your application code.
Luckily, most drivers can do the joining for you, if you set up your schema right.
For further reading I actually recommend Martin Fowler.