Take a look at this benchmark of fast sd-cards:
http://www.tomshardware.com/reviews/compactflash-sdhc-class-10,2574-7.html
Many cards are hit the SD-bus limits (+-20MB/s) for read-speeds, and come close while doing sequential writes, have excellent random-read-I/O, but completely suck at doing random-write-I/O. only very few cards are actually acceptable in that area... (most notably, the sandisk extreme class 10, but it looks like that card's using an out-of spec speed in that test, so the results aren't entirely valid...)
For an OS-card, that random-write-speed is going to matter. A LOT. (unless you use a log-structured FS like NILFS or logfs, that happen to neatly work around that, but you can't readily use those on the Pandora yet...)
I can't find any speed-info of the internal NAND, but it's formatted using UBIFS, which also neatly handles flash's erase-issues* (that FS can only be used on direct-acces (MTD) flash though)...
So I expect the internal NAND to be fastest for most users.
* raw flash is read to and written to in 512Byte-blocks, but can only be erased in far larger clusters. Flash-devices that are used as block-devices use an internal logical-to-physical-block(or erase-cluster)-mapping, manage a list of empty erase-clusters, and whenever you write to a non-empty block, most devices have to copy the entire erase-cluster around to another empty cluster, incorporating the changes. It then adds the old cluster to its list of available empty clusters, erasing it somewhere along the way. The modern-day good SSD's use more intelligent, but quite processing/memory-expensive ways...
Flash can, however, also be addressed directly, without that block-device-layer. The linux-kernel calls that MTD's (memory technology devices), and has a couple of filesystems designed specifically for them. They're log-structured (they write all of their new data to the end of the log), resulting in them basically not having to issue erases until the device is completely written to. UBIFS is the newest, best-performing one.