Implementing it and presenting it your users once is easy, and not that obtrusive. Doing it N times is not, and the complexity multiplies. It also increases the complexity of support. I see it as avoiding design decisions instead of making them. Since I don't see it as a viable option, I imagine they don't as well - it doesn't take must insight to realize you can provide an external switch to go between two different behaviors.
Compatibility switches hinging on different versions for different features in the code are basically unrelated.
Sometimes multiple switches affect the same area of the code. This is fairly linear. E.g. if the same logic is affected by two version checks, basically the behavior is split three ways: the ancient behavior before those two versions, the behavior starting with the older of the two versions up to before the later one, and then the new behavior starting with the later version. The code variants do not grow exponentially in N (the number of places in the implementation where a version check is made).
That could happen if you introduced individual Boolean controls for individual behaviors rather than a linear scale on version: the same area of code being "hit" by three run-time flags for altering behavior could have 8 possible behavioral combinations and up to as many blocks of code to implement them.
I don't see how it avoids making design decisions. If you have a plan for somehow mitigating the impact of backward-incompatible changes so that users can get through them, you have more freedom to uproot bad design and replace it with good design.
I imagine they don't know about the technique.
Engineers who know about rejected alternatives tend to mention them, to avoid the embarrassment of someone else doing it for them.