If we did it that way, the whole thing would have to be digital, which more or less defeats the purpose of the knob approach. With digital, you can only do discrete steps, so you're better off sticking with just switches and not sacrificing that key.
Not true at all. With a rotary encoder you can control the timing between steps far more easily than you can control adjustments using keys. Small adjustments and sweeping changes are equally easy and equally quick to accomplish. Scroll wheels are fiddly, but they're far easier to operate than trying to scroll with arrow keys, which move by exactly one step no matter how hard you press them.
What you say is correct.
However, if the OS support isn't there, you'd need a driver to be able to tap the extra granularity the encoder provides, which is beyond the scope of this project.
For scrolling, OS support is good for granularity but bad for specifiying context -- since it was designed for scrollwheels on mice, not keyboards.
For volume control, it's the other way round -- context is good but granularity is very mediocre, since the OS assumes you're pressing buttons. The wheel would just simulate button presses. You'd get better control for big vs. small sweeps, but you'd still be stuck with whatever default minimum increment the OS provides.
The only thing that seems the least likely thing to need the dynamic range of adjustment control afforded by a rotary control, is keyboard illumination!
You may be right. I don't use backlit keyboards, so I have don't have much experience with this.
With screen brightness, I often find that I want more granularity than is offered by the arbitrary digital steps the OS provides. Of course, screen brightness and keyboard brightness are not the same thing.