You don't use a screwdriver to drive a nail, and you don't user a hammer to drive a screw. Its good to use the right tool for the job. In many instances, a relational database (often SQL) makes a lot of sense and is the right tool for the job.
Some workflows, a NoSQL/Non-relational database design can be nice. Document databases, K/V stores, etc can be more optimized for those specific use cases which can lead to some better experiences. That said, lots of relational databases are quite powerful and quite performant that unless you
really need the particular use cases the NoSQL databases focus on, it may just be better to use the tooling available in your relational database.
There are a few instances where I've really preferred using a document database. Things like logs are often really useful to have in a document database like MongoDB. In one collection I can stick all kinds of logs. The schema of all the different fields in the document are really relevant to what kind of things I'm logging. If I were to have a column for every field I might have in the log message, each row would have a ton of null columns. If I wanted to add a new field to easily search on, I might have to add a new column. A "schemaless" design can then be very useful. Of course this is true of pretty much any document database and not necessarily only MongoDB, and these days some relational databases have decent JSON document database functionality as well. There are always certain kinds of tradeoffs to be made when choosing one database technology over another.
Another thing I've found useful with MongoDB in particular is GridFS, that has been pretty neat to use. These days there are other systems of handling binary blob storage, but as mentioned earlier there are always tradeoffs with choosing any particular technology.