Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler (reinterpret_cast. ie, undefined behaviour), or you need to break encapsulation to copy the fields over from one object to another.
Of course we could use an opaque pointer to our objects instead, but if your solution is to cast anything to (void*), where could that possibly go wrong?
OOP inheritance is pretty much doing that, but in a constrained, statically enforced way, which prevents programmers from making elementary mistakes or trying to make assumptions about the way hardware works.
Of course, the last example of the singleton works, but it also doesn't help to explain why we might use singletons in OOP. If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally. In the author's solution, we must treat each specially at the call site, which also violates our open/closed principle - we want to add new mixers without hacking (and breaking) the existing code.
Still, I pretty much agree that we should rethink the way these are taught. Perhaps every student should write his own OOP language before being let loose with it.