I think the above probably isn't right...
The 4060 counters have a built-in oscillator. My guess is that it starts them at the same time and the alarm is when they don't have the same number...when there's drift as compared across the two oscillator sources. And that the clock dial probably changes the speed of one of the oscillators, so they match well enough to stay in sync for the rough desired period.
All that to say the random distribution is probably based on the variability between any two 4060 counters.
Lesson learned: we built a 42-node several petabyte storage cluster. Worked fine as we were starting small, and got bigger, and bigger. When we “had it” and disconnected from our internal network and moved to an isolated network we discovered quickly that the timebase on all the systems drifted very quickly to be seconds and then minutes out of sync after several days. This was because they couldn’t access NTP.
Set up an ntp server and “resolved” it, except now we had an entire cluster of hardware that was (in lock step) drifting out of sync with the rest of the world. Fixed that. Moved on.
Another example: we bought a bunch of really cheap LED ropes to make our LGBT+ pride float’s backlighting for a pride parade several years ago. I wired it. The ropes were all independent and we planned to have them rotate colors. The little controller boxes had a mode that would smoothly transition through presets. It turned out that simply turning on the power would cause the lights to start in sync, and then quickly drift out of sync in a really mesmerizing way. They’d occasionally come back together but frankly it was better than anything we could’ve programmed.
We also learned we could control the rate of the “smear” by over or under volting the LEDs a bit.
Even if it’s digital, everything is eventually analog. And analog is weird.