Co-processors aren't out of the question, and I have found they are useful for additional interfacing. For example, in the past I have used several networked controllers to divide a system into smaller independent parts. In this case, the sample rates on each controller can be increased since each controller completes the main loop faster.
Also, if you are doing a lot of floating point operations, keep in mind the PIC18 controllers in the IFI controller do not have hardware implementations of the floating point math, so you are chewing up extra instruction cycles with every floating point operation. There are companies that make floating point co-processors, like micro-mega (
http://www.micromegacorp.com/).
As for a FIRST application, I have floated the idea of a co-processor for additional sensor feedback. Why have the IFI controller do all sorts of processing to determine if a (generic) sensor is within a limit when a co-processor can do it? Better yet, why not have a co-processor decode all encoder inputs? This will limit the number of interrupts that occur on the IFI controller, and expand the number of encoders you can use. This can be done with PIC18 processors that Microchip sells for about $5 a piece, provided you are willing to buy the necessary programmer. Also, your students would already be familiar with the MPLAB IDE.
So, even if you don't want to move all the way to the GUMSTIX level, you can 'roll your own' with Microchip, if you are willing to invest some money ($200) in a programmer.