While that would change the distribution of threshold hues (partly due to the non-linear mix of blue and green, as sRGB transfer function wasn't inverted), it shouldn't change the conclusion itself. Also it would be hard to constantly change the lightness in such systems, as the #0000ff green would have a much larger lightness than the #00ff00 blue and there are some gaps outside of the common sRGB or even P3 color space.
Pure RGB primaries gives an easy target for “red” and “green” endpoints but that’s about it. Ideally the test should consider two endpoints with uniform lightness and chroma, and just shift the hue to form in-betweens. The transition from blue to green in RGB (or HSL) is not linear in these attributes.
That is what I believe the original comment meant to say: convert to some color space where linear interpolation for non-hue axes would be meaningful. In my knowledge, such linear interpolation will require the tone mapping due to out-of-gamut colors, and the tone mapping itself is fairly subjective.
Even if you were to use a more saturated ramp, I suspect that discontinuities due to gamut mapping with a good algorithm[1] should be less than the discontinuities due to lightness and chroma shifts in HSL, but I could be wrong.
Ah yeah, I only checked the path between sRGB #0000ff = oklch(45.2% 0.3131 264.05) and sRGB #00ff00 = oklch(86.64% 0.2948 142.50) which surely needs out-of-gamut colors. And as you have noticed from the post, there are many algorithms to handle them with different attributes of colors to preserve. CSS even has its own algorithm [1] that primarily keeps hue and lightness but allows slight alternations to avoid excessive reduction on edge cases. For the purpose of this test though, hues should be probably preserved at any cost.
While lower saturation may solve this problem, some colors do greatly depend on saturation to be correctly perceived, like brown, so I don't think it is not ideal to change that either.
