On the other hand, for most use-cases users will be using a shitty old monitor not only uncalibrated, but with "digital vibrancy" and "sharpness" or whatnot set to 1000% and all careful color design is pointless. You have to design to what users will be using, just like game developers test their games on toaster-PCs.
I've had many situations that I tell someone to "click on the button in that blue box over yonder" and they reply "what blue box?" because the light-blue background got washed to white on their screen.
True, but you have to be able to support both. And unless we actually have a coloraware workflow for everything, the "too much/too little" contrast war won’t ever end.
Personally I've got a Dell UP2718Q right next to a Fujitsu Siemens P17-2, with two decisively different color, brightness, and resolution experiences, and try to make sure everything I design works well on both of these displays.
It is, but most systems aren't using a color managed workflow. And sRGB content on an sRGB screen looks exactly the same as on a DCI-P3 panel if you're using a color-managed workflow.
The only issue is that less than 15% of monitors today actually match the 95% sRGB, 300 nits, 8-bit panel specs which e.g. DisplayHDR 400 sets.
Just think about it, 85% of monitors can't actually display all CSS colors, and that doesn't even begin to handle issues like AdobeRGB, DCI-P3, and other WCG content.
On a true sRGB/300nits/8-bit screen #414141 on #dddddd contrast is actually fine (and meets WCAG guidelines, btw).
But if you display this same contrast on a 6-bit 150nits ~70% sRGB panel (standard cheap monitor from 2014) you won’t be able to read it under most conditions.
I've had many situations that I tell someone to "click on the button in that blue box over yonder" and they reply "what blue box?" because the light-blue background got washed to white on their screen.