Short answer is 'bugs', possibly even in the reviewer's own software. Opus (and I would fully expect AAC-LC) preserves time alignment. Something unknown, somewhere unknown, in an unknown part of the unknown software chain caused an unknown shift, and it's not necessarily by an integer number of samples. You can't use this 'enh, whatever, good enough' approach and expect to do meaningful null analysis, even if you're using it inappropriately.

In all seriousness, every aspect of this comparison is somewhere between deeply flawed and invalid. No point dwelling on just one part.

I imagine the lossy encoding process could use a bunch of stacked filters to cut away imperceptible frequencies, but filters in the general case are implemented by summing delayed copies of the input and can smear the output in the phase domain. (There’s a branch of filters that avoid this but require computing the introduced delay and shifting the output to compensate.)

It’s a noticeable problem in audio production if e.g. a filtered kick drum goes out of phase and sucks amplitude when mixed with the original.

Is it possible to run the recorded input through the filters twice, doing the second pass in reverse to cancel out the phase shift?

Yeah, I think that’s traditionally the route when you’re not running with near-real-time constraints. I’m out of practice with DSP/filter math but I think there’s a constraint such that any theoretical filter that doesn’t impact phase must be symmetrical around the time axis such that it requires “knowledge from the future” that’s not available in real time.

EDIT: And I think with the two-pass approach you need to calculate the filter such that you get the desired effect after two applications instead of one.