For computers, you could use a complex number since it's effectively a cache of sin(a) and cos(a), but you often want general affine transformations and not just rotations, so you use a matrix instead.
That makes sense in some contexts but in, say, 2D physics simulations, you don't want general homogeneous matrices or affine transformations to represent the position/orientation of a rigid body, because you want to be able to easily update it over time without breaking the orthogonality constraint.
I guess you could say that your tuple (c, s) is a matrix [ c -s ; s c ] instead of a complex number c + si, or that it's some abstract element of SO(2), or indeed that it's "a cache of sin(a) and cos(a)", but it's simplest to just say it's a unit complex number.
The advantage of complex numbers is to rotate+scale something (or more generally move somewhere in a complex plane), is a one step multiplication operation.
I can give an example from real life. A piece of code one of my colleagues was working on required finding a point on the angular bisector. The code became a tangle of trigonometry calls both the forward and inverse functions. The code base was Python, so there was native support of complex numbers.
So you need angular bisector of two points p and q ? just take their geometric mean and you are done. At the Python code base level you only have a call to sqrt. That simplifies things.
For many operations you can get rid of calls to trigonometric functions, or reduce the number of calls necessary. These calls may not be supported by standard libraries in minimalistic hardware. Even if it were, avoiding calls to transcendental can be useful.