Quaternions usually match artist's intent, and Euler angles usually don't. glTF isn't alone in using quaternions. I did a bunch of FBX imports a while back all

Quaternions usually match artist's intent, and Euler angles usually don't. glTF isn't alone in using quaternions. I did a bunch of FBX imports a while back all the orientation channels are just quaternions. It makes sense, because it's one natural way to interpolate rotation data, just based on the orientations of bones during the keyframes. The kind of stuff that you interpolate using Euler angles is going to be stuff that is naturally on gimbals, like cameras, tanks, robots, turrets, and stuff like that. You can do that easily enough by adding another node to your transform hierarchy with quaternions, but if you started off with Euler angles, you don't really have a way to back out. Quaternions are not always right, but they are the right default. If you want Euler angles, you can always translate to-from quaternions. Quaternions are independent of the way you set up the coordinate system and each axis is equal. Unity, for example, uses quaternions internally. It exposes getters and setters for Euler angles that do the conversion to/from quaternions as a convenience. The editor edits Euler angles but they disappear as soon as you are in-game, and if you open up your scene file in a text editor, you'll see m_LocalRotation with the x/y/z/w of a quaternion. I believe Unreal is the same way. Honestly, that just makes too much sense. Trying to do a physics simulation with Euler angles is just adding extra steps, because Euler angles are not easily composable. If you want to compose two Euler angles to get a third, the easy way to do it is to convert to quaternions, multiply, and then convert back to euler angles. You can see Euler angles in the editor when you are animating a model, but most of the time you are just dragging stuff around on screen or matching mocap data and quaternions make 100x more sense than Euler angles for representing that stuff. My sense is that any code which does a lot of trig, when there's an obvious way to write the code that does no trig, should probably be rewritten to eliminate the trig. A little bit of sin/cos/tan is fine but as soon as you are doing round trips with acos/asin/atan, you have to start considering where the branch cuts are.