I read this a couple months ago and was worried as well so I opened a ticket asking more details about this. Unfortunately, it seems the answer was given to me by phone as I can't find any answers in my emails that I could copy/paste here.
Basically, what I was told is that the documentation is misleading. What they mean by "pruned" is that if your data on disk gets corrupted (hardware failure, Windows file system bug, etc.), you wouldn't know about it since you never actually try to read/write data to that disk sector again. Doing a real full would copy every single file to disk/tape and ensures you have a valid copy of the data. As you can see, it isn't nearly as bad as it sounds when you read the BOL. Support told me it definitely wasn't Commvault that would prune the data since the retention would get updated with each synthetic (and incrementals for that matter).
The thing is, if I'm not mistaken (would need to verify that with support),with deduplication enabled, this would actually also be true even if you did a real full backup as the Commserve will only look in its DDB to know if it has the blocks or not and will not actually double check if it can read the data off the disk.
As far as missing missing files, I guess you either trust incrementals or you don't and If you don't trust the incrementals of your backup solution, you might as well buy a new one. Years ago, there were often issues with many products where an incremental wouldn't catch somes changes (mostly attribute changes like security permissions, etc.) but now those changes are being backed up as well (make sure to read each data agent documentation as some types of scan will not detect those changes). Since then, I've yet to see a restore missing files/attributes because an incremental missed it.
I don't have Exchange so I can't say for sure but I'd beleive that if you make a verification of every full, it would include synthetic full backups as well. I personally have a schedule that verifies my fulls every week-end and the verification expires 4 weeks later (meaning I check every full once a month). Also, if you do an aux copy offsite for DR purposes, you will have a copy of your data on another set of disk/tape reducing even more the odds of having such a failure.
As for synthetic full vs full, I personally only swear by synthetic fulls. I've used TSM for a long time with their incremental forever and never had any issue so I'm not expecting to have any issue using Commvault's implementation of the "incremental forever". Obviously, I always check the option box to run an incremental just before the synthetic full so that the end result is exactly as taking a full backup (but faster and taking up less space).
In the end, you gotta remember that your best defense against any restore failures is to actually do restore drills (good for DR tests as well) 1-2 times a year. Boring and annoying as hell but necessary, no matter which product you use. In my opinion, this should always be done as the issues are most often caused by misconfigurations made by the backup administrators (excluded files by mistake, forgot to include that new server that was installed a couple months ago, etc) and not so often by the actual backup solution.
Hope this helps.