No math discussed in here yet, so I feel obligated to contribute.
OP said that they average 8 with "most solves are within 4 seconds of each other."
We can model this by a normal distribution with mean 8 and standard deviation 4, call the probability density f(x). (Of course maybe not 100% faithful to the actual time distributions but it's the best model we can assume.)
Getting 4.292 in the first place is exceptional by almost 1 SD, but the point of interest is the odds of "twice-in-a-row" so we'll ignore this. We'll just care about the chances of getting the exact same time on the second solve.
For the small interval [4.292, 4.293) which would display the same time, we can approximate the chance of the time x landing in that interval by f(x)·Δx = f(4.292) · 0.001 = 0.0000649 = 0.006% chance.
Quite impressive statistically, but external factors aside of course
Great stuff^. Now that we’ve done probability, can we do expectation? How often is this likely to occur?
Assume 100 solves per day.
Probability that two successive solves have exactly the same time = 0.00006
How many “chances” per day?
With 100 solves, there are 99 successive pairs:
(solve 1 & 2)
(solve 2 & 3)
…
(solve 99 & 100)
Each pair is an independent opportunity for this coincidence to occur.
Expected number of identical successive results per day:
99 x 0.00006 = 0.00594
So on average:
~0.006 occurrences per day
Convert that into “how often”
1/0.00594 = (approx) 168 days
So if you do 100 solves per day, you would expect two successive solves with the same time to occur about once every 5½ months (roughly once every 168 days).
You tend to get certain times more than others due to turn speed and average move count. There is no probabaility, though I think integration in calculus may help with this (which I forgot more times than 3bld). This is honestly not that rare, happens to me many times.
I could believe that there's a strong quantisation effect for extremely short puzzles (e.g. floppy cube), and maybe even sprint events like 2/skewb/pyra, but for the longer events, the variance contributed by inconsistent execution times is more than enough to smooth out the fact that moves are quantised.
You may instead be noticing that the timer isn't truly running at 1000 Hz and has results that are quantised, rather than that you (the solver) are actually solving the cube with quantised times.