I'd guess pin-count and driver availability. SPI has pretty well-established kernel drivers with usermode access. Using the parallel busses is either going to involve driving a ton of GPIOs or trying to map some kind of parallel peripheral into driving each screen.
I guess that's a good point; I've been looking into some small TFTs with hand-solderable MCUs that fall short of application processors like this, but still run at ~50-200MHz. Not quite the same ballpark.
Still, on those, it's still only 13 pins for an 8-bit parallel bus (which I think can still do 16-bit color,) rd/wr/dat-cmd/chip_en/reset, and the chip_en/reset pins are probably optional. And while they do tend to have a few hardware SPI peripherals, some of them also have flexible memory controllers which can rapidly pipeline data over a customizable interface designed for use with a variety of RAM/storage/etc banks. But I think it will probably work since TFT interfaces are essentially writing to a framebuffer. And BGA packages usually have like twice as many 'pins,' but to be fair 'real computers' do also require a lot more I/O than microcontrollers.
Yeah, when I said that I was thinking of the WEIM in the iMX6 chips, which I'm pretty sure could be persuaded to talk to a little TFT. The tricky part, once you've got the electrical bits figured out, is getting the memory peripheral (WEIM or FSMC or whatever) talking to the screen, and then putting together whatever glue of a driver to get from userland to the hardware. And then hoping that it generalizes to another screen, or putting in whatever effort is necessary to port it to another screen.
It's a pain in the butt compared to just opening /dev/spi0 or whatever and writing a few bytes to it. Don't get me wrong, I'd love to have a great library of cheap OLED screens that could talk to an RPI/BBB in a high refresh rate way, but for the majority of my own projects I'll just take whatever cheap SPI screen I can find and use that.
