My take as a graphics programmer is that angles are perfectly fine as inputs. Bring 'em! And we'll use the trig to turn those into matrices/quaternions/whatever to do the linear algebra. Not a problem.

I'm a trig-avoider too, but see it more as about not wiggling back and forth. You don't want to be computing angle -> linear algebra -> angle -> linear algebra... (I.e., once you've computed derived values from angles, you can usually stay in the derived values realm.)

Pro-tip I once learned from Eric Haines (https://erich.realtimerendering.com/) at a conference: angles should be represented in degrees until you have to convert them to radians to do the trig. That way, user-friendly angles like 90, 45, 30, 60, 180 are all exact and you can add and subtract and multiply them without floating-point drift. I.e., 90.0f is exactly representable in FP32, pi/2 is not. 1000 full revolutions of 360.0f degrees is exact, 1000 full revolutions of float(2*pi) is not.

Hah. I think we're and the author of both articles on the same page about this. (I had to review my implementations to be sure). I'm a fan of all angles are radians for consistency, and it's more intuitive to me. I.e. a full rot is τ. 1/2 rot is 1/2 τ etc. Pi is standard but makes me do extra mental math, and degrees has the risk of mixing up units, and doesn't have that neat rotation mapping.

Very good tip about the degrees mapping neatly to fp... I had not considered that in my reasoning.