The first uses oklch(0.65 0.20 300), comfortably inside sRGB, not even at the boundary. The second uses oklch(0.65 0.28 300), which is well outside P3 and even Rec.2020.
The smallest fix would be to make the second one oklch(0.65 0.2399 300) to bring it inside P3 so the demo doesn’t get slightly warped if Rec.2020-capable (not really necessary, but preferable, I’d say), and the first #a95eff (oklch(0.6447 0.2297 301.67)) which is CSS’s fallback.
But purple is also pretty much the worst choice for such a demo—P3 adds the least to sRGB around there, so the difference will be smallest. A better choice is red or green.
So a better pair would be oklch(0.65 0.2977284 28) on the right (a bright red at the very edge of the P3 gamut, well outside sRGB) and #f00 on the left (the sRGB value CSS will map it to if out of gamut).
One last thing:
> This way the browser uses OKLCH colors if they are supported, otherwise it falls back to sRGB.
This wording suggests it’s about gamuts, but it’s actually about syntax. It will use the oklch() if that syntax is supported, and then the OKLCH value may be within sRGB or may be in another gamut the screen is using or may need to be mapped back to the screen’s gamut. Whereas #rgb values are inherently limited to sRGB, the baseline.