Applying the rotation that a quaternion represents is done via multiplication. This is really neat, because it works on vectors, like so:
v2 = q * v1
but also on other quaternions:
q2 = q * q1
...which means that combining rotations is quite easy. The downside is that, compared to euler angles, it's a bit more difficult to immediately translate between your intuition of what a rotation is like and its quaternion representation (although I find that quaternion rotations seem far less arcane if you think about angle-axis rotations, since there is a very straightforward conversion between the two).
For your case, since you know the Euler representation of the rotation you want, you might want to just convert that directly to a quaternion and multiply it by the current rotation every frame (note that the order matters, quaternion multiplication is not commutative).
I'm not sure if glm has a built-in conversion between the two models, but the answer I linked before has several examples of how to implement one if you need it. So, once you have the
eulerToQuaternion function, you can do something like this:
Quaternion q = eulerToQuaternion(0.01, 0, 0);
pawn.rotation = q * pawn.rotation;
Also, as to whether it's a good idea to use quaternions or not, it kind of depends on what exactly you are doing, but I think the general consensus is that yes, they are the most convenient way to work with rotations. The wikipedia page on the subject says:
Compared to rotation matrices, quaternions are more compact, efficient, and numerically stable. Compared to Euler angles, they are simpler to compose. However, they are not as intuitive and easy to understand and, due to the periodic nature of sine and cosine, rotation angles differing precisely by the natural period will be encoded into identical quaternions and recovered angles in radians will be limited to [ 0 , 2 π ].
Which sums it up pretty well, I think.