Good point Jeff ... we run our DEV databases in FULL recovery model, and we restore to point-in-time FAR more often than a production database ever has done!!
But we also grow the TLog like crazy trying-this and trying-that and periodically have a who-did-that blame session! and downtime running manual scripts trying to get things back to normal. I think it would be better that I invested the time to have all the DEV databases shrink any unruly TLogs files back to "normal" (e.g. overnight). "Normal" for us would be somewhat tight ... we have 20 databases in DEV, I suspect that I haven't touched 18 of them in 6 months ... tomorrow I might have an urgent need though. I can live with fragmentation and somewhat impaired performance on DEV, but I don't have huge amounts of spare disk space. What I do have I would prefer to give me more backup history [without having to wait for a restore from tape] than more log space
In our case we don't restore PROD over DEV, we back-merge data from client PROD data tables into DEV. Normally our program meta data, and the table structures, in DEV is ahead of the PROD version (except just after a new version rollout, natch!) so overwriting the lot would not be helpful. But if I needed a TEST copy of a database so that I can run some diagnostics then I would favour a restore of PROD to TEST and shrinking it to waste less disk space seems reasonable. I'd never get sanction for 10's of GB for log files that never needed it on TEST ... but I can imagine in much bigger shops it would be critical that the hardware in TEST was identical to PROD and everything would be like-for-like. (In reality most of our TEST DBs are on the PROD server, its the only one we've got on which we can experience real-world loads and performance, if the code gets from DEV to TEST it is deemed ready for release, so TEST is only to prove that all is well and check performance before the code gets deployed onto PROD, or to make some diagnosis of a problem on PROD.
Sorry, my apologies, I've wandered off into a general discussion ...