[Symmetry]

Yeah, probably if I'm understanding it right. This one seems less correlated with OoO than Meltdown or Spectre. It looks like you're just issuing a load based on FP register state you shouldn't touch. The system eventually notices it needs to have issued an exception based on the access to the FP register and eventually does quash the load within the core but the the load has already gone out to the memory hierarchy where you can see its effects on cache levels even though it never completes. Larger cores are harder to stop all at once than smaller cores so being OoO should correlate with being vulnerable but basically any pipelined processor that can throw an interrupt on register access could theoretically be vulnerable to something like this.

[caf]

I think you probably do need to execute the should-fault FP access in a not-executed speculatively executed branch (à la Meltdown), so that the exception doesn't actually fire and the kernel doesn't reload your own FP state.

(Since you can only learn a small part of the state each time, you need to have the other processes state remain in the FPU while you repeat the process to learn the entire AES key or whatever).

[Symmetry]

It might be that the check of who can access the FP registers versus what the identity of the current process is takes a few clock cycles due to communication across the core and Intel didn't want to slow down the critical path register load for this since they figured they could just squash any improper execution later. But it might also be as you say.