There is scan_whole_pool_milliseconds, which currently forces bgwriter to circle the buffer pool at least once every 2 minutes. It is currently fixed, but it should be trivial to turn it into an experimental guc that you could use to test your hypothesis.
I recompiled with the variable coldly set to 1000 instead of 120000. The situation is slightly degraded (15% of transactions were above 200 ms late). However it seems that bgwriter did not write much more pages:
You should probably try it set to 200 rather than 1000, to put it on an equal footing with the checkpoint_timeout of 0.2 seconds you reported on.
As I understand it, the setting makes the bgwriter processe scan all shared_buffers every this amount of time... but ITSM that the key point is that bgwriter has no insentive to start writing out buffers anyway with its current decision rules, and that should not change with the frequency at which they are scanned (?)
Ah, I see now. The usage counts are not zero, so it visits the buffer and then leaves it alone.
