Adding another frame to the "sprite" object seems to have a performance impact as well (about 25%) But it only happens if you set the speed to anything else than 0.
Yeah, this is another deliberate optimisation which only applies some of the time. Animated sprites need to be ticked to advance the animation frame, but to avoid the ticking overhead for static sprites, if it has only 1 frame or an animation speed of 0 it doesn't tick it at all. This is so all your static scenery and background objects don't get the overhead of ticking if they're not animating. It will start ticking if you set the animation speed greater than 0 (and it has more than 1 frame), but one quirk is it never stops ticking that instance until it is destroyed, i.e. it assumes it will always be animating thereafter.
I think this is pretty reasonable, the main goal is to remove overhead from static objects, and it does the job. However it's true that we could refine this a bit so as sprites stop playing animations they also stop ticking, and only start again when they start animating again. I've made a note to look in to doing that for the C3 runtime.
Adding something to the quadissue test and measuring the impact seems to be a good way to measure the engine overhead of various features! I'd warn though that the overhead isn't necessarily always important - for example in the animated sprites case, I would guess for most projects sprites either animate or don't, so the ticking overhead issue probably isn't particularly significant.