As far as I know, it's not so much the hardware that causes the flicker as it is the programming. I think nodtveidt once even told me that it's possible to program a demo which shows the max number of 64 sprites on screen moving without flicker, or maybe that was for slow down. It seems that all the Irem games for TG16 suffer bad flicker even with only a few sprites on screen.
The hardware doesn't cause flicker; it does something worse! Sprites disappear completely if there are more than 16 sprites (256 pixels in total) before them on a horizontal line on the PCE. (Count how many segments in the "snake" on stage 2 there are on any single line...) So the game code/programmer has to cycle the objects into the different slots in sprite RAM so that the lesser-priority objects aren't always invisible. Of course, this causes flicker for the rest of the objects, but at least everything's mostly visible now.
Irem games flicker a lot for several reasons. Of course, they could have coded the games a bit better, but Hudson did the R-Type port, so...
Anyway, a lot of Irem games run in a wide horizontal resolution, around 352 (?) pixels wide. This means that a lot more objects/sprites are likely to land on the same line than if it were running in a resolution like 256 pixels wide. Add to that the fact that the maximum number of sprite pixels on one scanline is 256 and you have about 96 pixels of space on the screen where sprites cannot appear without employing flicker.