> The answer is it’s not about what you use to represent your rotations (quaternions, matrices, or rotors), it’s about how you apply those rotations.
Also, the article didn't mention this exact method. It's unclear what he's referring to.
In this case if I understand isoclinic rotations right, what you would do every time you want to rotate your vector is construct this pair and multiply by the left and by the right to your vector.
Now what do you do when you're implementing the keyboard event to rotate by all 6 planes in 4D? Do you store 6 pairs of Quaternions, each pair changes when you press the corresponding key, and those are applied to your object every frame in a specific sequence?
If so, this will gimbal lock.
You can call this an "incorrect implemention", but Gimbal lock isn't a bug so much as a real phenomen that can be modelled with any rotation of representing rotations.
This will not gimbal lock.
Regarding using 4x4 matrices: This will result in unintended shears and stretches due to rounding errors. Renormalising the matrices will be complicated and expensive. Also, interpolation will be more complicated and expensive.
And Quaternions of course have several advantages and you should use them for those reasons.
The goal of the article was simply to explain that avoiding gimbal lock isn't the main reason you should consider Quaternions, which most people commenting here seem to have already been aware of.
AFAICT, this shouldn't gimbal lock.