By TTL do you mean UART (where a peripheral receives/ sends out a serial stream automatically) or bitbanging (where you manually set/reset/toggle bits)?
I would probably recommend SPI. It's a relatively easy protocol, and on the master side, if you have to, you can bit-bang it. (But much easier to use built-in SPI peripherals.) The SPI master sends out a clock line (SCLK) and a data line (MOSI = master out slave in), where the data bits are valid on a designated edge of the clock line; it receives a data line (MISO = master in slave out) from the slave where the data bits are valid on a designated edge of the clock line. If you have multiple slaves, the technique is usually to have one chip select (CS) line for each slave; if CS is low then the slave in question is active, otherwise it's supposed to ignore the clock/data signals and not disturb the MISO line. SPI is simple and will even work with an HC594 or HC595 output register (tie MOSI to SER, SCLK to SCK, CS to RCK) if your microcontroller is short on output port pins and you need a few extra ones. If you have more than 3 SPI devices, consider using an HC138 as a decoder to produce the individual device CS lines from a set of address bits and a master chip select line from the microprocessor. (since only one CS line is supposed to be low at a time)
I2C is a pain. Its main advantage is that you can do everything in 2 wires (+ power and ground) shared among a bunch of peripherals. But you have to handle address contention and a bunch of other things. It's also slower than SPI and has open-collector lines so its power consumption + noise immunity are related to what you use where for pullup resistors (or current sources).
A UART can be the fastest solution. SPI has a speed limitation related to the round-trip propagation time, since both sides use the same clock signal. (signal path = master changes SCLK pin, slave sees it and responds by changing MISO pin, then master uses MISO signal on the next SCLK edge so the signal from the slave should have arrived by then) In a UART, the incoming and outgoing bitstreams are independent, and latency doesn't mean your throughput is reduced unless the high-level protocol is for UART endpoint A to send a command to UART endpoint B, wait for B to respond, and then send the next command. Really fast serial streams should consider using LVDS to maintain signal integrity. But parsing UART bytes is kind of a pain compared to SPI; in SPI there are distinctly delimited packets, whereas in UARTs you are dealing with an undelimited serial stream and any packetizing has to be done from parsing the data itself.
edit: one other plus with a UART, is that sometimes the processor can automatically handle large send/receive buffers, so that your program can queue up a big glob of bytes to be sent, and then parse a bunch of received bytes when you feel like it. The hardware can handle the immediacy of sending/receiving each individual byte, and frees your program from worrying about missing individual bytes that arrive when your program is doing something else.