This is very late, but I can confirm the same bug exists on DSi, and I don't think this is caused by any compatibility problem. It's very easy to induce with a program like this:

GFILL 0,0,255,191,2
FOR I=0 TO 31
 SPSET I,I,0,0,0,0
 SPSCALE I,I,180
 SPOFS I,RND(256),RND(192),180
NEXT

As far as I can tell, this is a hardware limit, based on a section of GBATEK:

Maximum Number of Sprites per Line
The total available OBJ rendering cycles per line are
  1210  (=304*4-6)   If "H-Blank Interval Free" bit in DISPCNT register is 0
  954   (=240*4-6)   If "H-Blank Interval Free" bit in DISPCNT register is 1

 The required rendering cycles are (depending on horizontal OBJ size)
  Cycles per <n> Pixels    OBJ Type              OBJ Type Screen Pixel Range
  n*1 cycles               Normal OBJs           8..64 pixels
  10+n*2 cycles            Rotation/Scaling OBJs 8..64 pixels   (area clipped)
  10+n*2 cycles            Rotation/Scaling OBJs 16..128 pixels (double size)

Based on this, I think I was drawing too much unnecessarily, as every sprite was 64x64, so I guess it's not surprising I hit the limit fast. Seems using smaller sprites may be a fix, though, so if I ever go back to that program I'll have to switch to smaller sprites until very large ones are necessary.

In regards to my original issue, it's technically fixable, but the problem is likely a hardware limit and the solution is to work around it.