If I understood correctly, this is CPU-based, use of GPUs is not covered? How useful is this approach? Does it necessitate "unlearning" some ideas when transitioning to something like Vulkan?
To be honest, it's fairly specialized knowledge, though fundamental.
First edition used Pascal, then C and the third uses a mix of C++ and C#.
GPUs and graphics APIs used to have to implement a huge number of graphics features for you to get anything on the screen. You used to give the GPU your vertices that defined polygons, colors at each of those vertices, textures (and texture coordinates for each of the vertices) and few parameters to control some interpolation math, and then the GPU did everything to put them on the screen. Features like fog and lights and shadows all needed a specific function to perform them, and you didn't have a lot of control over how exactly it would work. If you wanted to do crazy stuff like non-Euclidean warping of space, you were basically not going to do that on the GPU.
Shaders were invented sometime in the late 80s (originally as a CPU-based rendering system, IIRC) but they didn't really hit the game industry until about 15 years ago, and it took some time after that for them to get popular, both for hardware to propagate in the market and because it was a pretty huge departure from before. The GPU does a lot less for you, now. Instead of giving you functions to specify numeric constants that control output, it gives you a block of memory and a space to run code to use that memory in a structured way. Whereas before you would give the GPU your projection and camera and model matrices and it would transform things for you, now it doesn't care how you define the transforms, you put whatever matrix or some other construct you want into memory and you do the math (well, at the algebraic level. You don't implement matrix multiplication) to transform the vertices. You want a light in the scene? The GPU doesn't even know what a light is anymore. Your "light" is a color and intensity value you load into the GPUs memory and then you write the code that figures out what color a lit polygon will be. It doesn't know what fog is, what shadows are, what bump/normal/displacement maps are, any of it. To the GPU, all of that stuff is just big blocks of numbers that it lets you run your own code over.
The GPU still has a black box function for converting polygons to pixels (or rather, fragments as they are now called, as they don't necessarily map 1-to-1 anymore). This is the strictest definition of "rasterizarion", but it's a small part of the whole process and a "software rasterizer" does a lot more than just rasterization. All of those things that aren't just figuring out pixel coverage of polygons, this are pretty much up to you, and learning to do it in a software rasterizer can be great for learning, because graphics APIs aren't exactly the nicest things to work with.
Even still, if you never end up writing shaders, I think there is a lot of good to learn in the process. You might find yourself in a situation where all you have is a 2D graphics library and you need to create 3D-looking effects, for generating static images or lighting up grids of LEDs connected to a microcontroller (both examples of places I've personally used the stuff I learned in college... 15 years ago).
As a loose analogy to a non-graphics topic, fixed-function pipeline GPUs were like SQL engines. They gave you declarative means of controlling state on the GPU. If what you wanted to do didn't have a function for it in the engine, you were in for a bad day. Programmable-pipeline GPUs are like Hadoop clusters. There is some data and you define some kind of pure function that map/reduce over it. It's more work for you for simple things, but it provides you the maximum flexibility to do creative things.