Yes. We have applications running on both PostgreSQL and MongoDB and I find that working with MongoDB is just more pleasant. I think it mostly boils down to my preference of document databases as opposed to relational ones. It feels much more natural to me to embed / nest certain properties within a document instead of spreading it across several tables and then joining everything together to get the complete data. MongoDB makes working with these sometimes nested documents easy (I mean, it better) and there's always Aggregation Pipeline when you need it (something that I again find much more pleasant and readable over SQL).

What always irks me is when somebody suggests PostgreSQL's json (or jsonb) types as an alternative to using MongoDB. All it's saying is that the person hasn't really invested a lot of time into MongoDB because there are things that PostgreSQL simply cannot do over a json type, especially when it comes to data updates. Or it can do that but the query is just overly complicated and often includes sub queries just to get the indexes into the arrays you want to update. All of that is simple in MongoDB, not really a surprise - that's exactly what it was made for. The last time I worked with PostreSQL's json I sometimes ended up just pulling the value out of the column entirely, modified it in memory and set the it back to the db because that was either way easier or the only way to do the operation I wanted (needless to say there are only exceptional cases where you can do that safely).

Lastly, if you can easily replace MongoDB with PostgreSQL and its json types or you're missing joins a lot (MongoDB does have left join but it's rarely needed), chances are you haven't really designed your data in a "document" oriented way and there's no reason to use MongoDB in that case.