This only matters if the mainline kernel since then somehow experienced changes which would affect this hardware vulnerability (fixed through microcode), which I see no indication of?

CPU vulnerabilities are first fixed through kernel mitigations, only sometimes through microcode.

But security research should be done against the current state. Something as simple as a performance optimization can end up affecting the exploitability, and while that doesn't change whether the CPU is vulnerable it does change the conclusion.

Evaluering if a particular old, forked codebase is security-wise is identical is a fools errand, and then that doesn't answer whether an equivalent Red Hat kernel is vulnerable as that's a different fork with different backports and local patches. Mainline is the shared base.

I don’t quite understand how that matters here. The researchers found a CPU vulnerability. They demonstrated it on a popular Linux distribution and LTS version, Ubuntu 24.04. They likely picked that to show that the attack is not purely theoretical, but feasible on something that real users currently use for real things. There is a microcode fix available that solves this problem, presumably across all OSes and releases. Whether the kernel is current and how much it diverges is, frankly, irrelevant.

They are not just looking for vulnerabilities, they're demonstrating impact which is kernel dependent.

The kernel has numerous CPU bug mitigations that change kernel behavior to make the CPU bug ineffective for active exploitation (microcode rarely fixes bugs other than just disabling a whole subsystem - they usually take silicon iterations to fix, and the kernel has to pick up the slack), and current kernel design choices may also unintentionally render the vulnerability ineffective.

That's why they specifically say what OS and version they're running, exactly because it is crucial. It's just that they are not, in fact, up to date when it comes to the kernel.