All programmers at a certain level must understand the lower levels of the stack they are building upon. I think most people can get by with just learning the abstractions that are provided to them. With time people can learn more and more about lower levels as they specialize. Most people who become graphics programmers don't need to know the low levels of how a GPU works, so I personally do not think that is a good place to start for people who want to get into graphics programming.

Are you a graphics programmer, or are you just saying this because that's true in the CPU world (where you have experience)? From both my own and my colleagues' experiences, I would 100% disagree: the nature of GPU architectures means you are forced to deal with super low-level details from the very beginning. Part of this is because graphics (and GPGPU compute) programming is inherently performance-constrained: if it wasn't, you could just do your work on the CPU with much less of a headache. Even just generally though, the path to running code on a GPU is much simpler — the hardware does less work for the programmer, there's no operating system to manage threads, everything's a single binary, etc. — which means that there's less to insulate you from what's underneath.

>Are you a graphics programmer, or are you just saying this because that's true in the CPU world (where you have experience)

Neither.

>the nature of GPU architectures means you are forced to deal with super low-level details from the very beginning.

Not everyone is trying to push the hardware to its limits by making the best thing possible with the hardware. Plenty of projects can get along fine with a A/AA renderer or with unoptimized shaders.

>there's no operating system to manage threads

There literally is. Or if you disagree the firmware manages the threads.

>Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary, is very deeply tied to a good understanding of hardware.

I'm not entirely sure I agree in the modern day sense. Especially if our analouge is webdev. So much of industry is using UE and Unity that you probably can be a "graphics programmer" professionally without ever knowing what a vertex buffer is (only slightly exaggerating). Your ultimate job is either to a) make images look better b) make images run faster or c) make sure images can get put into the engine properly. And a high level understanding and implentation of shaders/texturing concepts and understanding which settings run slower on those engines (even if you can't explain them in detail) can get you pretty far in those regards.

you're certainly SOL once you move out of your engine of choice, but you can definiely be productive enough to get hired if you got a foot in the door.