So if you have a bunch of things occluding each other, they can all get rendered on top of each other even if only the closest is actually displayed.
Sometimes people try to avoid that by not drawing stuff that is occluded, or drawing in order of depth, or discarding fragments if the depth buffer has already drawn over a location with a nearer texel, or that sort of thing. But it's always a PITA to calculate/sort that sort of thing in realtime.
Once per pixel is fine when you're teaching the hello world of shaders.
But I've actually kind of been thinking about that, too. Think about how much 'magic code' most 'hello world' tutorials have that you're told to just ignore. That can also be off-putting when there's too much of it.
I wonder if there's a happy medium for introducing the basic concepts, like starting with microcontroller assembly instead of 'std::cout << "hello, world";'.
Then you won't have to explain things like '#include' because your students will already know that it just means 'pretend I copy/pasted file X here' from when they learned how to make an LED blink.
Anyways, I guess this particular resource does look like it struck a pretty happy middle ground for beginners. I just hope they don't get discouraged trying to branch out with self-teaching; there are a lot of byzantine 'gotcha's with graphics APIs and parallel stuff.
I think the big thing with introducing new things is keep it simple enough that they can riff on it. If you introduce too many things and something breaks, it's hard to get back to "good" and eventually you give up.
Python is a simple language, but I see a lot of online classes giving full-on VMs because the yak shaving involved in getting set up with a consistent environment wastes the first week or two of class.
Written by people who know what the topic is already, so I think they miss that I went into this not knowing if they were talking about computers or some art form or ink and pen style or whatnot.