Note that their hue and lightness values are almost same. The only difference is saturation and that seems to be why they are on the same row, differentiated only by the saturation axis.
Yeah? Well … you know, that's just, like, your opinion, man. More specifically, HSL's opinion. HSL is a fine colour space for specifying CSS colours, but not so good for evaluating lightness.
If I use HSLuv instead, which is supposed to be like HSL, but more human-perceptually uniform and sane (basically a neat compromise between CIE Luv/Lab and standard HSL), I get a lightness of 61.2 for cadetblue and 91.1 for cyan.
My bog-standard image editor uses HSB (a.k.a. HSV) in the HSL-style mode of its colour picker (HSL isn't even an option); and if I measure cadetblue with that via the ‘eyedropper’ tool, I get a brightness of 63%, whereas cyan has 100%.
Those are obviously way closer to the truth when you just, like, look at the colours — it's totally plausible that cyan is about 50% brighter; “lightness values are almost same” is not plausible.
This discrepancy isn't a huge problem, because the main dimension by which this tool organises colours is hue, which HSL is OK at. Only the way in which colours with similar hue are laid out on the page is off. It would be nice to see a more appropriate colour space used for this purpose.
I was commenting based on the HSL values of the mentioned colors. At the time of creating this tool I really didn't care too much about using a more perception-aware color space. Doing it just based on HSL already seemed like a huge win. But I received similar feedback in the past, too. So thanks for pointing out. I'll maybe think about making it even better in this sense.