The data loss issue comes up in failover scenarios with replica sets. Data gets into the master but not yet mirrored to slaves. Then the master goes down. When the master comes back online the data in that instance waiting to be committed sometimes never makes it into the replica set.
It should be noted that MongoDB does provide some tools to help reduce the possibility of data loss on failover.
Write Concern specifies a minimum number of nodes that have to return an acknowledgement of the write. If an operation does not receive the required number of acks in time, it returns with a write concern error. This doesn't mean the write failed, just that it took too long for X number of nodes to acknowledge the write.
Write Concern is useful in that it can help the user keep track of any writes that might not persist in the event of a failover. If you have a write where a majority of nodes have confirmed it is written, it's pretty unlikely that data will be lost during failover.
Read Concern is 3.2 only, and as I understand it only works on WiredTiger storage engines. Using ReadConcern ensures the only data that is read is data that has been confirmed as written on the majority of nodes. So there might be newer data, but the data you are reading exists on the majority of the nodes.
I think, in general, not using write concern properly or not using it at all probably has led to some level of data loss in the past - in some systems, it may not be feasible as speed of writes is more important than acknowledgement of writes, but in that case, some level of data loss should probably be expected.
Ignoring complicated replica setups for a moment, as I couldn't comment on them, although I have had no data loss from the old style master/slave replication.
Most of the documented instances where MongoDB has been losing data has been user error. There are the common causes:
They were running the 32bit version, and ignored the big warning when you start it up saying 'do not run this, you may lose data' (to be fair, if you installed early versions from some repos it wouldn't show that error).
They didn't specify they wanted write acknowledgement (with safe/fsync/w parameters) and it defaults to fire-and-forget, arguably a bad default, but they didn't read the docs either, this itself shouldn't lose data randomly only if there was a power failure or crash.
They did specify write acknowledgement but didn't actually bother checking if the write succeeded. I've seen people doing if(!db.insert(...)) { error }. But if they had read the API docs it's clear that that function call doesn't return false on an error, instead you make a new call to getLastError(). This isn't really any different to running a query against any other database, but not bothering to check if there was an error. Again, user error from not reading documentation.
I've never lost any data in the 5 years I've had an instance in production.

Hi Mark,

From the Adapt side, the only way that the database would be cleared is by running the install.js script a second time (this requires user input at various points, so wouldn't be something that could happen accidentally). 

What does the database look like now -- what collections do you have (if any)?