Arguments for MongoDB backup with OpsManager or mongodump?
It might not be a full answer (as others will have valid opinion) but I am ok with not getting credit.

Argument in favor of OpsManager:


Continuous backup, you can recover up to the last committed transaction.
You can set your retention one time and do not have to worry about it.
You can automatically make multiple copy of your backup for redundancy.
Restoring non production environment (DEV/QA/INT) in matter on minutes.
mongodump excludes the content of the local database in its output which is problematic for sharded cluster and replica set.
mongodump only captures the documents in the database in its backup data and does not include index data. mongorestore or mongod must then rebuild the indexes after restoring data.
mongodump can adversely affect performance of the mongod. If your
data is larger than system memory, the mongodump will push the
working set out of memory.
Mongodump is not suitable for large databases. This is from official documentation.



  The mongodump and mongorestore utilities work with BSON data dumps,
  and are useful for creating backups of small deployments. For
  resilient and non-disruptive backups, use a file system or block-level
  disk snapshot function, such as the methods described in the MongoDB
  Backup Methods document.
  
  Because mongodump and mongorestore operate by interacting with a
  running mongod instance, they can impact the performance of your
  running database. Not only do the tools create traffic for a running
  database instance, they also force the database to read all data
  through memory. When MongoDB reads infrequently used data, it can
  evict more frequently accessed data, causing a deterioration in
  performance for the database’s regular workload.