This misses the point: the example claims the hue isn't shifting, when it very clearly is. It's not a question of why.
It's normal and expected for saturation to change. And for brightness to get clipped. But not for hue to change.
That's the critique of OKLCH here, that changing hue is a bizarre and undesirable choice.
(Since this reminded me of it, a random pro tip: For those using macOS Terminal.app, you can redefine the 16 ANSI colors using the full P3 colorspace, so long as you use the full GUI color picker rather than the sRGB-limited #rrggbb entry method. Access to improved saturation helps the eye distinguish different shades in the dim and bright color sets more effectively without having to alter their brightness. It won’t improve the limitations of ANSI color as a whole — the insistence on Luminosity = f(R,G,B) is baked into everyone’s assumptions quite deeply thanks to sRGB! — but it does at least mean you can have seven equidistant and non-desaturated, non-sRGB colors at two levels of brightness for syntax highlighting and other typical 16-color uses.)