This is a current topic in Beta testing a version of GFAM and DSFL that does allow the application to check if the client is allowing a write within a certain timespan [the beta does adhere to setting, but still prints the checkpoints to the log]. The [to me ancient] 60 second interval is still there from the days that we were on single processor CPU's but now 4-6-8-12-24 processors on a CPU becoming normal, running that many tasks could results in getting also that many writes to disk of progress with performance impact. Not the same for all as the storage sub-systems are not all equal.

For longer had it on 5 minutes [300 seconds] to mitigate and did see some efficiency improvement, 1 percent and better [very easily observed with BOINCTasks multiclient monitoring and managing utility]. Now have it set on my Linux 64 bit [24/7] quad to 900 seconds, and running very long DDDT2 B-Type 'pe' series of 17 hours and longer and observing another 0.1% improvement [running at 99.85%]. Not a huge amount between 5 minutes and 15 minutes, but why waste cycles when the system is only booted when there is a kernel update [less often then a blue moon]. When needing to do a system restart, planning it by switching back to 5 minutes WtD, park any CEP2 ready to start, and postpone boot until all cores are loaded with short checkpointing science apps, then do the 30-45 second restart cycle.

So, what's your setting like [even larger?] and do you observe gains? It's not a OS platform dependent consideration [works for Windows and Mac of all too]. There must be a reason why the option is still there after all these years.

--//--

P.S. In Client 7 [first alpha out] the local pref will be called "Tasks checkpoint to disk at most every xxx seconds". ('to disk' probably maintained as a generic reference though SSD's and usb memory sticks storage or not 'disks').