Some good news about performance for once.
As I mentioned earlier, I had tracked down the Flash performance hit to either Compressor or FlixExporter. I now think it's a combination of both.
Essentially, if we tell the Compressor software to store its temporary files outside of the default location, disk accesses for the Flash plugin go through the roof. While this fundamentally seems to be a bug in Compressor (and I've reported it to Apple), the FlixExporter seems to blow it way out of proportions. Flash jobs were using, at most, 40% of the available CPU time.
For now, I've switched to a secondary Flash encoder - this time, the default Quicktime plugin which comes with Flash 8 Professional, instead of the separate On2 product. You get less control over the final video this way, but I think it'll be Good Enough(tm) for now.
While this plugin still stuffers from the Compressor issue, it's at most suffering from a 12% performance hit, instead of a 60% (or more) performance hit.
As an aside, the reason that we're using a non-default storage location for the compression cluster is that it allows us to get rid of the annoying "preparing video" step. During that step, your whole video had to be copied off of the RAID array and onto a local harddisk. This was a major time hit, and also meant we had to set aside extra storage on the local machine. By placing the storage on the RAID, your video starts processing as soon as you hit submit - on larger jobs, this could save you up to 10 minutes of processing time.