Steve, sorry for your loss. It sounds like knee-jerk and brain-dead. Applying a blanket solution with no good reason is terrible.

Often folks that have had issues with log growth on databases are alarmed at the file sizes. Once the log growth is controlled a shrink of the log portion might be OK.

OK everybody else check me on this. SQL server is a bit vulnerable during a shrink operation. A full backup should be done right before it. If not then be prepared to know where all the backups since the last full till now reside. If something goes bad during the shrink then a restore is likely to be needed.

Usually SQL Server does a wonderful job of reusing pages. So if you have a lot of pages that are unused then SQL Server will use those pages rather than grow the file. One of the things that a shrink can do is to move all of the used pages toward the front of the file and drop the unused space at the end of the file.

I know that I'm not being real specific here but there are a number of options to shrinks and I don't have specifics about what is actually being run.

You might inquire if the DBAs that wrote these plans have a background with Access. That often required a Repair/Compact to avoid it losing its way.