For each sprite displayed on a scanline, the hardware fetches two bytes from memory, and then clocks the pixels out one by one. The sprite is eight pixels wide, and each pixel is two bits, which is why it's two memory accesses per sprite per scanline. You can imagine that this arrangement just needs a couple of shift registers to clock the pixels out.
Now, flipping the sprite about its vertical axis is easy: you just clock the pixels out in reverse order!
Similarly, flipping the sprite about its horizontal axis is also easy: You just fetch the bitmap from memory in reverse order.
But if you wanted to rotate the sprite 90° or 270°, that's much harder. That's because the hardware would need to get one pixel from each pair of bytes, which means fetching 16 bytes from memory instead of just two. I don't think there's enough time on this slow hardware to do that. Rotating by 180° of course is the same as flipping both horizontally and vertically.
It's a similar story on the Commodore 64, the Atari 2600, and many others: These platforms can do some simple 2D manipulations on sprites like stretching and sometimes flipping like you've seen, but never rotations.