I have no concrete evidence that the game in question uses 2D graphics, other than my intuition. I played some Command and Conquer in the past and I think they are 2D, for how they look and for the age of the game. If they hand draw the sprites or if they used renders from a 3D editor like 3D Studio is another topic.
What libraries the game installed/required, like DirectDraw, Direct3D, etc, I don't remember. So I cannot guess based on that.
OK, now for the problem at hand. If I have to use sprite sheets for whatever reason: I don't want to mess with 3D data, target hardware doesn't handle 3D very well, etc. I would design the tanks in at least two parts. This means that the body of the tank (lower part) will be rendered/drawn separated from the cannon (upper part).
Why this design? Because I can rotate the cannon independently of the body without having to save an entire sprite for each possible combination of body/cannon positions.
Also I would use Blender (place your 3D editor/modeler of choice here) to design the tank parts and then produce renders of the different positions of the parts and combine all of them in a single sprite-sheet.
So, with this design, you have the freedom of moving the parts of the tank individually without having a super large sprite-sheet at the negligible cost of multiplying the calls needed to render a single tank by a factor of 2 (there are worse things you can do to hurt the performance of your game).
For example, if we want, as many old RTS games, for each thank, the positions: left, up-left, up, up-right, right, down-right, down, down-left (turns of 45 degrees). We only need 8 renders of the body and other 8 of the cannon. If we want turns of 22.5 degrees, to have more appealing visuals, we need 16 renders of each part, for a 32 in total, so we end with a 32 sprite long sprite-sheet.
If we were to render all the tank as a single sprite, and we still want to be able to turn the cannon without turning the whole tank, then we need a render of the tank for each possible combination of body/cannon positions. So, in the case of the 22.5 degrees, the following formula should tell us the required renders: (360 / 22.5) ^ 2 = 256
The reasoning begin that formula is, that for a full 360 turn in steps of 22.5, we need 16 renders per part, but if we were to render the full tank retaining the individuality of the cannon, then we need 16 renders per body position (because each body position will have 16 versions, each one with a different cannon position).
Note that, some game out there, for whatever reason, may opt for using a 256 sprite long sprite-sheet. Maybe because they don't like the increase in code complexity required to render each part in the correct place (probably not so complex) or they just don't care because the tanks graphics are low-res and the saving in storage/RAM doesn't convince them.
I don't have concrete evidence that the game in question do the rendering of tank parts separate, but I guess It does.
Also note that the game you put as example doesn't allow +1 or +2 degrees of rotation. RTS games of the time had only a very limited set of positions per unit, never +1 degree, is more in the order of +22.5 or +45. Even in the case of hand drawing the sprites with an artistic sense of isometric perspective, they still only have to draw 8 or 16 positions. The limit is imposed by both: artist time and hardware capabilities.
For example, Age of Empires 2 sprite-sheet example: http://vignette1.wikia.nocookie.net/ageofempires/images/a/ad/Hussar.png/revision/latest?cb=20160126073526
And another evidence: I still remember that when you clicked on an unit in the map editor of AOE 2, you see an octagon at the bottom of the unit. If you have this game around don't try this in an actual match because during matches the game shows an isometric rectangle, the octagon is shown in the map editor when placing units. This gives us the clue that the units has 8 possible directions. I'm sure they rendered more than 8 sprites per unit as the units moves in place and have fighting, moving and standing animations, but that's another topic.