You're right, CPU time is burnt by stackdepth_walk().
The underlying issue is that max stacksize is computed a bit pessimistically with the new opcodes (JUMP_IF_{TRUE,FALSE}_OR_POP). On normal functions there wouldn't be a sizable difference, but on pathological cases such as yours, a code object could end up claiming a large stack size (as large of the number of such opcodes) rather than a very small number.

Still, of course, stackdepth_walk() should not blow up when computing a large stack size, but fixing the opcode's stack effect in compile.c seems to fix the issue anyway.