use cases for db.collection.validate() - checks the structures within a namespace for correctness by scanning the collection’s data and indexes
There is no prescribed need to run db.collection.validate(true) on a regular basis for a healthy MongoDB deployment. Validation with the true or {full:true} parameter can be resource intensive, as this iterates through the collection's data &amp; index structures.

The validate(full) command is typically only used as a diagnostic aid in the event of suspected local data corruption or (for WiredTiger in particular) to true up collection counts after an unclean shutdown. As at MongoDB 3.4, validate() is a read-only command with the exception of validate(true) which will check &amp; adjust collection counts if you are using the WiredTiger storage engine.

Validation generally only surfaces obvious problems in data structures, and cannot detect all possible forms of data corruption. Successful validation can be used as a sanity check if one of your replica set members is encountering data problems that result in an obvious assertion and you want to verify if other secondaries appear to be healthy. If full validation is unsuccessful on a replica set member, the general remedy is to resync the member rather than attempting to repair (which may result in a divergence of data from the other replica set members).


  We have regularly unclean shutdowns.


If you have regular unclean shutdowns and are using WiredTiger it would definitely be advisible to run validate to true up collection counts after a restart as these may be inaccurate. Ideally it would be preferable to investigate and resolve the issues or practices leading to your frequent unclean shutdowns.