I think you might have a fairly narrow definition of "Sound Programming."
As has been pointed out, ' sound programming' can be some of the most intensivige game coding someone can do...
I like to lump "sound programming" into 3 broad (sometimes overlapping) categories.
1) Sound Implementation programmer. This sounds like what you probalby think of. That's the programmer (often an intern ;0) whose job is to sprinkle the code with calls like "PlaySound(SNDTag, Parameters); through the game. (it can be quite a bit more than that, of course). Sound Implementation is usually, but not always, pretty straightforward
2) Sound Engine/Tool programmer. These programmers write the high-level sound engines that perform things like real-time streaming, data file parsing, etc. That requires pretty good knowledge of real-time and system programming. They may need to write entire (friendly and robust) User interfaces that a sound designer or composer will use when creating content. They are the essential link between content and code in content-driven audio development systems.
3) low-level audio signal processing programmer. These programmers typically need to know assembly language like the back of their hands as well as the complex mathematics behind the processing of audio. FFTs, DFT's, MLTs, IIR, FIR filters, data compression/decompression algorithms. That's pretty heavy stuff. And there's a ton of stuff going on out there. People do entire PhD dissertations on things like physical modelling of sound, real-time analysis of music, or environmental modeling..
So there's a lot of "meaty" stuff in game audio programming-- way more so than it may seem on the surface. Video game music and sound design still need a lot of specialized code to make it work