I would love to use axis-angle, because it's so straightforward, but the only solid issue I can see that puts quaternions out ahead of all other options is rotation concatenation.

If you have an object, with its orientation in axis-angle form, it's not very easy to apply rotation to its existing orientation. I've been working on this problem for a few days, in the hopes of coming up with something as efficient as quaternions insofar as compactness and efficiency of concatenation, and the best way to use axis-angle is by converting to quaternions to perform concatenation, which then requires converting back to axis angle. To my mind, this would just be a lot better to just get rid of the intermediate part and just make it the representation used.

No matter what I use, at the end of the day I still have to submit orientations to the GPU in the form of matrices, but anything I can do to speed up physics calculation is a win. Axis-angle, in this instance, is not the best.

I would love to use axis-angle, because it's so straightforward, but the only solid issue I can see that puts quaternions out ahead of all other options is rotation concatenation.

There is, in fact, a way to concatenate axis-angle rotations. A quick Google search led me to this thread: http://www.gamedev.net/topic/542932-how-to-sum-rotations-vector--angle-/

tl;dr Basically, to concatenate two axis-angle pairs, you convert them to matrices, multiply them together, then convert the result back to an axis-angle representation.

Here is something I will say negative about Quaternions and positive about Euler angles, which is shocking I suppose to hear from any programmer. What I'll say is, neither are perfect, but combined can work fairly well. It's culture shock I suppose from every developer who obviously knows that gimbal lock is a problem. However, how does actual gimbal lock happen? (I have to say "actual gimbal lock" because I've read articles that simply say that reaching a singularity at 90 and 270 degrees, which can be easily worked around, causes a "gimbal lock". Actually, that causes a crash if your compiler caused an exception it didn't gracefully handle, thankfully C# and .NET just return a NaN.) I define actual gimbal lock as the loss of a degree of freedom caused by the rotational dependency with not applying all rotations for each axis at once, which the Quaternions do. Let's get into the actual problems with Quaternions though.

Firstly, consider the method of approach to get Quaternions, you take the cosine and sine of each angle divided by 2. If your original angles are clamped between 0-360, you're already losing some information. That's why every Quaternion to Euler formula that I see has a problem in getting the actual original Pitch angle, calculating by Arcsine, including the ones on Wikipedia and Euclideanspace. I actually spend a few days testing and figuring out things about Quaternions in depth, and found a better, but not perfect, process by which to get the original Pitch back, which I'll explain momentarily.

Here's what I found. ORDER matters at every stage in the Quaternion process. In Unity for example, if you're going to recreate Unity Quaternions from scratch for mathematical testing, you'll find very quickly that when you try to pull back an Euler you'll get the wrong angle unless you specify YXZ in the creation of the Quaternion by "sandwich products" (that is... q * V_in * q^-1), and then create the rotational matrix in ZXY order.

Once you've done all that, you get not one but two potential orientations for your original Euler angle, which mathematically works, but is annoying if you've ever seen an engine like Unity bring back a weird angle with the X flipped around 90 and 270 degrees while the Y and Z get flipped by 180 on the second angle retrieved from this Quaternion to Euler conversion, and you want your actual original angle back. If you don't do it right, you'll get some weird flips on some rotations from what it should be if you convert back to Euler and then apply it somewhere. I tested with all 36 permutations, and found that only the way I specified works with Unity, that alone tells me that Quaternions are not some magical unicorn of mathematics. It also tells me why Euclideanspace mentioned differences in NASA standards and how they had to do some flipping of signs and what not to get rotations to work.

In other words, Quaternions aren't exactly one size fits all like the internet claims, you'll have to test and see for any engine you work with what order the Quaternions were actually applied in because it pertains to the accurate way to retrieve said angle, but then, when you do, because you don't have real accuracy in getting the pitch angle back because it's obtained by Arcsine, you'll have to basically make a decision between two angles that are equivalent, which is fine from a mathematical perspective, but not so great from a data perspective.

So, how did I sort of fix it? Well, by creating a second Quaternion in the conversion process that has only the pitch obtained from the Arcsine and the other angles zeroes out, testing both rotation angles to see which one has a roll/yaw closer to 0 than the other, which will be either -180 or 180 on both angles. It works unless your roll and yaw are both close to 180, then it flips.

So what I'm saying with all of that, is that it's not the best in the world for human readability simply based on the problems of Quaternion to Euler conversion.

Imagine for whatever reason hypothetically that you're on a spacecraft marooned in space, there are no planets around, but there is a Black Hole. Let's say that you decide to go into said Black Hole since it seems like there's no other option. As you enter the Black Hole, your instrumentation uses Quaternions and it's getting you the angles back in Euler so that you can read them, but the angles keep on flipping because you're spinning around in a Black Hole, but maybe somehow not dead yet, and for whatever reason not nauseous, so even though you're ok, your instruments are going haywire because they keep flipping which Euler angle to pick, spinning out of control and you have no sense of actual direction. While a ludicrous hypothetical example, I'm simply conveying the fact that it's not the end-all be-all of rotational systems, despite whether it's computationally fast, or stores less information, etc.

Also, just a pet peeve of mine on the internet. It's not the Euler "angles" that are the problem, since they can be easily converted to Quaternions. it's the actual rotational math created by conventional formulas to rotate said Euler angles that suffer Gimbal lock. Angles are just numbers, whether you specified 360 degrees for a rotation on an axis or 2*Pi, or even just 1 as a rotation. Quaternions on the other hand, just another representation, except that said representation basically gives you back the sine of the pitch and two other angles, leaving you with some lost data when trying to read it in a more human readable way.

When you dig down into the actual math and you understand that math is math, and not something transcendental or magical, you understand that Quaternions have their own set of problems, hence nobody I know seems to really understand them fully, and I've read tons of articles, actually tested the math, and made it my pursuit to explore virtually every aspect of Quaternions. At the end of the day, my take away was a desire to create a rotational system that applies all of the rotations for each axes at once to get around the Gimbal lock problem, with all the original Sine and Cosine information, not sines and cosines divided by 2 initially. By the way, axis-angle methods from what I understand have the same issue as Quaternions. I feel that a better solution exists somewhere, that's my take away of digging into the guts of Quaternions and Euler angles. In the meantime, I decided to build my own rotational system in Unity3D for some mathematical testing that essentially uses both Eulers and Quaternions so that a human readable angle is tracked. However, once you start multiplying Quaternions by themselves, good luck getting the original pitch angle back, essentially. I think of it as a lossy format the same way I think of jpeg. It's great that it exists, but I would like to have a png kind of end-all be-all solution for rotations that gives you all the connecting components from human readable angles down to the actual rotations applied and doesn't suffer gimbal lock. I imagine such a system potentially being more computationally expensive, but more robust as well. Maybe not something you would put in a game, but on an actual spacecraft. Understanding said math though, opens up lots of opportunities for understanding the full spectrum of rotations.

I don't have a mathematics degree as you have by the way, mine was in programming, at best I worked for the banks and I was on a team that won an AT&T Hackathon contest (which I detest because I would rather them call it a computer programming contest) back in 2015, looking back I should have gone for that math degree, but I would have most likely been buried in a realm of subjective proofs like I was in Discrete Math, only to write a subjective thesis to be subjectively graded for what should be an objective degree. I've been exploring this rotation problem and the spectral leakage problem in DSP (also related to cosines and sines) as of late. I simply thought that I would weigh in and give a quick... "Hey, I've been there, I know what you mean, I'm sending my sympathetic and even empathetic condolences, even though others in the game community may scoff at this post, claim inaccuracies by quibbling over semantics, and so on. Ask me if I care what they say personally, I'm interested in mathematical innovation, as are you quintessentially. You've got a whole generation of programmers out there that try to beat you into acceptance of imperfect standards at every turn on StackExchange and other sites just because they're afraid of getting in with a little mental elbow grease,  sure it causes brain pain, but I think this is one wheel that needs to be reinvented."

P.S. My last girlfriend, whose father worked for Mission Control at NASA before he unfortunately passed away, actually laughed when I mentioned both Unity and Quaternions. I don't know if she's ever had any exposure to rotational systems, or understands the math, she worked as an administrative staff in some capacity there at NASA years ago. She was right to laugh though, amazingly, even if it was just at the silly hyped up name. I'm in some ways laughing now about Quaternions and in some ways not now that I've explored them at a deeper level, a better solution must exist somewhere, so I'm playing around with the numbers of Sines and Cosines and seeing if some of the techniques applied to Quaternions can be applied to some system that is more inclusive in terms of information. In some ways, I'm also laughing about Unity3D, and not in a good way, it's the engine I've grown dependent upon for rapid prototyping, but it has an exceeding number of limitations at every turn if you want to delve into things like, oh, say, setting a TRS matrix directly.

1 hour ago, John Ernest said:

Here is something I will say negative about Quaternions and positive about Euler angles

If your actual problem is only to get original euler angle numbers back after turning them to a representation of rotation, then this can't be an argument against quaternions or for euler angles. Orientation has little (quats) or no information (matrices) about the rotation(s) which caused it, so what you want can only work within conventions and restrictions you define for yourself (e.g. limiting angles to 0-360, euler rotation order, assuming zero as initial state as you do). This puts your whole post into personal experience with some assumptions and impressions, which is not helpful for anyone (mostly beginners) to choose the right tool for the current job.

Matrices, quaternions, axis and angle, rotation vector, euler angles - all of them are useful for 3D rotations, and nobody should shy away from any of them. Even if some are harder to understand than others, they are all useful and necessary at some point. Full understanding is optional anyways, otherwise quats would not be so popular