I have one application at the moment which needs to handle about 175k writes/second across AZ's. We are not sharding at the moment, but probably will once scale requires (we are getting close) -- so just one big replica-set and it's behaving .. really nicely. I tried to emulate this workload on Postgres (which is my favourite database over my entire career so far (many scars)) and we couldn't get it to where mongo was for this workload, multi-az is painful, automatic failover is still an unanswered question really, I've tried all the 'right around the corner' multi-master Postgres options and none of them did anything other than make us sad.
From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
Especially what helps is we have absolutely incredibly great support from MongoDB. We have a _weekly_ call with them with a bunch of their senior engineers who answer all our stupid questions and proactively look for things to improve.
Ops story is also good, we aren't using Atlas, but the on-prem kube setup while a bit clunky has enough CRDs and whatever to keep devops happy for weeks at a time.
tl;dr -- it's boring and predictable, and I rarely have to think about it which is all I ever want from a database. I'm sure we could achieve the same results with other database technologies, but the ROI on even investigating them would not be worth it, as at best I think we would end up at the same place we are at now. People seem to have deeply religious feelings on databases, but I've never really been one of them.
I would not hesitate to use it on a new project.
This sentence summarize all the issues developers working with Mongo will have: multiple version of documents living in the same DB and unpredictable structure
Best thing MongoDB have it's definitely their marketing (making everyone think it's amazing to invest hundreds of millions to deliver an "OK" tier database) and their customer support
You can argue that you can imitate that in Postgres or even SQLite by storing in JSON fields, but there are things they can't do quite as efficiently (e.g. indexing array contents); storage itself isn't very efficient either. But ignoring that, there's no functional difference: it's document in, document out. So then the choice boils down to speed, memory usage, etc. One day I'm going to check if Postgresql offers a real performance advantage, but given the backlog, that may take a while. Until then, MongoDB just works.
The mongodb instance is ephemeral, the database itself is ephemeral, both only exist while the script is running which can be measured in seconds. The structure is changing from month to month. All this plays to the strengths of mongodb while avoiding the usual problems. For eg one stage of the aggregate pipeline can only be 100MB? A source csv is a few megabytes at most.
Ps.: no, Excel can't do it, I got involved with this when the complexity to do it in Excel has become unbearable.