There's lots of open-source software from the drone community that works with gyros, and I might recommend some of that over the Altus Metrum code, which I find pretty complex and hard to follow.
A quick summary of what is going on. But I am by no means an expert on quaternions. Every time I think about them my brain hurts.
Quaternions describe rotations of 3D vectors and you can combine two rotations into one simply by multiplying the quaternions together. So the integration step is easy. Just multiply the current rotation by the small rotation given by the gyro measurement.
NASA Technical Memorandum 4775 goes through a lot of math to get to the same point. It is interesting reading though. It describes a project where they lift a UAV by balloon. When released at altitude it uses a small rocket motor to bring it from its initial nose down attitude to level flight.
This is where you can make an optimization. Converting those gyro measurements into a quaternion requires both a sine and cosine. Depending on the platform that can be expensive in terms of code space and/or time. If the rotation is small enough, you can use the small angle approximation where cos(x) = 1 and sin(x) = x. That is what I do since my data is collected at 32KSPS. Altos is running at 100SPS and a 2000d/s range so it tries another approximation. I wouldn't worry about it.
The maximum possible rotation in Altos is 20 degrees per sample. I suspect that if you have rotation anywhere near the 2000 degrees/sec sensor maximum you are going to quickly blow past your tilt threshold. Errors from the small angle approximation aren't likely to matter much.
One nice feature of this is that it is norm preserving. (Vector length = 1) Errors will creep in that denormalize the quaternion over time so you will want to normalize it occasionally but there is no need to waste time doing it for every sample. Once a second seemed to do just as well with my 32KSPS data.
So keep your starting quaternion set to zero rotation until you detect launch and then start integrating. Launch detect criteria should be such that the rocket is still on the rod/rail!
Measuring the angle is pretty simple as well. Use the quaternion to rotate a vector from your starting orientation to the current orientation and then calculate the angle between those two vectors.
This can be simplified a lot if the starting vector is something simple like [1 0 0]. Then you can skip the full strength quaternion multiply and dot products.
Note that you don't even need an arccos function here unless you absolutely require angles in degrees. If you store your threshold for disabling outputs as cosines of the angles, you can skip that. So you don't need anything more complicated than: add, multiply, and square root. Fixed or floating point is your choice. Speed is important as the quaternion multiply requires 16 multiplications.
If this is integrated within an altimeter, you only need to check the angle when you are about to fire an output conditioned on it. No need to waste time doing it every stinkin' sample.
I dug up the code I wrote when trying this on Glen Overby's data and whipped up a quick plot using some 32KSPS data. I tried to do three 90 degree rotations isolated to a single axis. The failure to return to zero could be because of a flaw in my code or non-linearity/cross axis sensitivity in the sensor.