There's no realistic chance of an exploit involving only .JBP files, since they're just read into memory without interpretation. An .MP3 exploit is much more likely, and there are documented cases of arbitrary code being executed on a PC by playing a malformed .MP3 in a specific player, but would be difficult without the source to the JB's player.
However, your idea of loading code in a .JBP would work well with my idea of hooking a microcontroller to the JTAG port. The micro would no longer need to load any boot code into the ARM; it would just set up a data-dependent watchpoint on the last word of the screen memory, wait for the watchpoint to be triggered (by the loading of an .JBP with the right value in its last word), then jump to 0xC1F40C0. The necessary JTAG code shouldn't take more than a K or two, so a much smaller/cheaper micro could be used than if it needed to contain the actual application or bootloader code. Furthermore, the code would never need to be changed once it's debugged, so users wouldn't need any in-circuit programming capability for the micro.
The result: for the effort of soldering a pre-programmed 8-pin PIC (or similar microcontroller) to the JTAG pads, you'd be able to run arbitrary programs of up to 56K in size, which could either be self-contained applications or something like a uCLinux bootloader, just by storing them on a SD/MMC card and selecting them in the built-in picture viewer. Normal operation of the JuiceBox would not be affected except for the slight chance of a video or picture containing the 32-bit trigger value in its lower-right corner.
