If you have a specific color in mind you don’t want to be picking a* and b* but instead hue h* and chroma C* (polar coordinates). CIELAB isn’t perfect here (there’s some hue shift as you change chroma in the purple–blue range), but it’s pretty good, considering how simple it is.

> You can scale [a and b axes] to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software.

Please don’t rescale the a* and b* coordinates. These are standardized and have remained consistent since the model was introduced in the 1970s.

> Its shape is also non-intuitive [...] hard to reason about

The gamut of RGB displays is not intuitive. That’s the whole point. If you squash it into a regular shape then people using it end up misled into thinking they are dealing with a regular shape.

In fact they are still dealing with the same weird irregular shape in terms of human-perceived color attributes, it’s just now their coordinates have been obscenely warped so they match the gamut but now have nothing to do with human perception.

So e.g. changing the HSL “H” parameter will not only inconsistently affect perceived hue, but will also dramatically distort lightness and chroma relationships between colors.

Anecdotally, having watched artists of various skill levels at work, this causes significant amounts of confusion. Pretty much everyone who uses HSL/HSV type models has no idea what they are dealing with, and the result is gross misunderstanding. When artists work with it long enough they can learn to work around it, but they end up with hilariously incoherent rationalizations and explanations for their heuristic techniques.

Believe it or not, working with perceptually relevant coordinates is more rather than less intuitive, even for complete novices, after just a tiny bit of explanation. This is because the model matches their first-hand experience. Moreover, because the model is consistent, formal knowledge aligns with experience and grows over time. It helps if the UI reveals what they are dealing with though. (For example, Photoshop’s CIELAB mode is not ideally integrated, and not very obvious to non-experts. But once understood it still makes the image editing process much smoother and more predictable.)

> To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on.

You always need this information to ingest an image from a specific camera or display an image on a specific display. If you [either you personally as an artist, or the software system you are working with] aren’t aware of the basic attributes of your system you’re going to end up with bad results.

There is no one “RGB”; every camera and every display is different. With some systems artists can let the software automatically make all of the choices along the way from image capture to display, but that would still be true under some change of working color space.

> uses it was designed for

The use CIELAB was designed for was colorimetric specification of surface colors, so that e.g. your plastic toy factory, paint mixing shop, or magazine printer could produce reliable results. It was designed to be simple enough that it could be computed in real time by hardware spectrophotometers of the 1960s–1970s.

But it also works as a pretty decent color space for judging human perceptual attributes. There are some better alternatives (IPT, CIECAM02, ...) but they are more complicated and less widespread.