Earlier quoted context omitted.
Not sure if that's related to Apple's original problem, but in the scenario you are describing, the fix is trivial: detect when level commands are dropped and retry (up to N times / for up to X milliseconds). And don't forget to check existing volume between steps 1 and 2, so you can be made sure what the previous state was. I don't think the "fighting" will be a problem at all - you'd have to to press volume control…
Who should detect, who should retry, and how? I don’t know the macOS audio stack in detail, but I work on state synchronization problems in distributed systems and my intuition for problems like this is that the “why not just” solution almost never solves such a bug completely.
I've made drivers for badly designed hardware, and it's really not not that hard when you control the pieces. I mean, if it was Windows with all that backwards compatibility stuff and drivers written by 3rd party manufacturer than sure, it could be hard.. but Apple controls entire software stack, so they have no such excuse.
And the most important part is that the problem is very error-tolerant. Sure, having random balance change once per day is super annoying. But instead, imagine having one random volume change command per day be ignored.. People would not even notice, it would be a great improvement.