There is one thing which just came to my mind, which might help in that regard! It could be a foolish idea as well tho'... Lol
I believe the HDD delivers data so fast on a request, that the timing and interrupts made in-between could cause this issues... (oversimplified short explanation, a.k.a. 'tl;dr')
Essentially, due to varying threading during runtime the 'answer-times' might 'jitter' a bit, thus leading to these weird test-results!
Just like the ping-example (websites), I posted before... Once the answer-time could be 47ms, then 53ms, then 28ms, then... I suppose you get, what I mean.
I SUPPOSE that some part of the code
@sp193 actually wrote for the streaming of BGM (in the SND-Thread) could be a good example.
The idea is to split the transfer-buffer into at least 2 (or 3) 'partitions' (possibly for all devices, not just iHDD) and change some things to the general IO-Management to be a bit less interrupt-driven (if applicable).
But this is rather a suggestion for a rather complex test and currently solely based on the tests since page 6.
This suggestion would not DIRECTLY change timings of the cdvd-emu-driver, but might affect it due to a bit different transfer-structure and thus different threading (thus possibly leading to less 'jittering' timings IF THAT IS THE CAUSE).
tl;dr2 If that is the case, than those issues could be related to possible 'race conditions' from some (partially) bugged game-code, which is triggered by too high 'answer-times'...
Again! This is a conclusion partially based on the facts and tests and partially on assumptions, because we have not (for 100% certainty) identified the culprit(s) of it(/those issues), in most cases (yet).
Yes, I state it when something of me is an assumption... lol
But it's still an assumption based on observations (the tests since page 6)!