I am assuming you have read all of those references because if you haven't we are back to square one.
The difference is actually there all the time. What is not there all the time is one being worse all the time (more on this at the end). From probability point of view, in a single experiment, it could have gone that way. We have no guarantee of randomness.
Here are is a possible scenario:
Test starts and to make sure all is well, they play the original .wav file. The kernel (OS) reads that file from the hard disk and since it is so small relative to system memory, it caches it meaning that the copy of the file exists in RAM now even though we have finished playing it.
Then the formal part of the test starts. The proctor plays one of the files. If he played the .wav file first, the OS has cached it and therefore there is no disk access. The music plays without the hard disk activity sagging the power supply or generating noise that can be coupled to the clock (other sources of course remain).
He then plays the .wav file that has been converted from flac. Since this is the first access to it, we incur hard disk reads to fetch it. So right there our test fixture is acting differently. But that is not the only system change. Usually the kernel fills its available disk cache (memory) as much it can so it rarely has space waiting for something new (I am oversimplifying a bit here). To make room for this file, it will have to "retire" some pages meaning it has to get rid of something to make room. If those pages are read pages, then they can just be freed instantly and used to cache this new file. If they are data that has not yet been written to a file yet, then they have to be "flushed" to the hard disk. Which is which is not predictable but likely some I/O will occur as statically we do X writes for every Y reads.
A typical lossless file is probably 30 to 40 megabytes. Let's say the file system block size is 4k and we don't get any read aggregation. That means that we incur about 8000 reads to read the file itself. Let's say we incur 10% as much for write so now we are up to about 9000 disk I/O for the converted flac file. None of which occurred when reading the original, non-converted .wav file. Relatively speaking that is a pretty significant difference between the scenario of the original file where we did no reads and the second where we did all of these reads.
Of course it is possible that they didn't read either file before they started. Since we were not there, we don't know if that were the case. It could have as well been the scenario I mentioned above. But even in this scenario we could get unlucky in the kernel may have done a lot more page flushes for the first file and then have space left over for the second and hence, incur less I/O. Either way, we can demonstrate scenarios where one file would be more favored than the other.
If you have read the articles then, and combined with the Linn measurements, you now know that system activity does cause fluctuations that can impact the sensitive S/PDIF clock that is on the PC motherboard (not "will" but "can"). The power consumption spikes could therefore be more in favor of one file playing and not the other. So it is *possible* that jitter and or electrical interference signature changed and hence the sound changed and that differential is what they heard.
I can't tell you how likely the above is. I can only show that is possible. If it is possible then we can't say with certainty that the results of a single trial that way is a "can't happen." But the good news about probabilities is that it helps us as they ran more and more tests and they kept getting "lucky" with stars lining up as they wished. Even then we don't have 100% confidence as they could have gotten lucky that way. That is why I said at the outset, we need to have the authors conduct some of the tests again in front of someone monitoring them. That is the only way we will know for sure. In absence of that, I am very comfortable saying their outcome is not realistic and not something I would live my audio life on.