That depends on your definition of "faster" which in turn depends on what you're doing with the communication channel.
Simple case: unidirectional
The "display" part of HDMI (let's not mention the embedded extras like I2C etc) is a unidirectional source synchronous serial link using multiple differential channels. This is the simplest as it is unidirectional. The sender uses specified protocol to pack data into frames and transmits them, the receiver processes it, but does not reply. There are no ACKnowledgements, no retransmission in case of error, etc. It is purely a stream.
This is similar to say, RS-232 Serial, SPDIF, UDP over Ethernet...
In this case, "speed" is purely throughput in bits per second. That's determined by your physical channel properties (bandwidth, noise, etc) as per Shannon's theorem which gives an upper bound for the capacity of a channel in bits/second. This is easy to grasp intuitively: more bandwidth means more capacity, and more noise means less capacity. In a real design, bit error rate is also a design parameter. Shannon's capacity is an upper bound, assuming a perfect error correction code is available. In practice, actual capacity will be lower, and the less errors you want, the more redundancy and "safety margins" you will need, which also reduces throughput.
How much of the available capacity is actually utilized depends a lot on the channel coding and protocol used. For example, using an error-correction code allows to increase throughput while keeping the bit error rate under control, up to a point. In some cases, like SPDIF an error-detection code is enough, and the receiver "hides" errors by interpolating over the corrupted sample. In other cases, like RS-232 serial, the bit error rate is assumed to be "low enough" and error handling is not implemented.
The protocol itself will also influence throughput, via packet headers which are overhead and consume bandwidth for example.
Harder case: Bidirectional
USB, Thunderbold, PCIexpress, TCP/IP aren't simple streams, they are bidirectional and both sender and receiver talk to each other. They may acknowledge that packets are properly received, request retransmission in case of error, etc.
This makes latency quite important. If packets must be re-transmitted in case of error, then the sender must keep in its own RAM all the data that has been transmitted but not acknowledged yet by the receiver, in case the receiver requests a re-transmission. Thus we have a design compromise between RAM size (expensive), latency (imposed by transmission distance, number of hops/hubs, packet size, etc) and throughput. Since a packet can only be ACK'ed once it is completely received and error-checked, smaller packets may be an advantage and offer lower latency, but there is more overhead for headers, etc.
For example, a LPC4330 microcontroller with 100BaseT ethernet and 64kB dedicated to packet buffer will happily saturate an ethernet connection with UDP packets. But 64kB is only 6.5 milliseconds worth of buffering at full throughput, so if you want to use TCP to a destination with a 30ms ping, it won't work. You'll have to lower throughput until you have enough buffers to keep all non-ACKed packets in case they need retransmission.
So there are lots of compromises at the protocol level to optimize performance for a particular use case, which is why there is no one-size-fits-all protocol.
Sometimes "faster" means "lowest latency" and throughput is only important as it reduces the time required to transmit N bytes of data, but the link won't be used at full capacity. As an example, SPI has very low latency (just the time to transmit a few bytes) but USB has quite high latency because "real-time" isochronous or interrupt transfers only occur on each µframe. Also USB has a lot more software and protocol overhead. So if you want to control something in real-time and you don't want extra phase lag in your control loop, SPI would be a much better choice.
Final boss: USB mass storage
Most of the time you're not just transmitting data for the sake of it, but in order to actually do something, for example read a file from a USB stick.
In this case protocol is extremely important for performance. Consider a transaction between host and device like:
Host - "Device, send sector 123"
Device - ACK
...device fetches data...
Device - sends data
Host - ACK
Host - "Device, send sector 124"
Each exchange takes time (latency) so a protocol that can do more things in less exchanges will be "faster" although it transmits data at the same speed, because it will waste less time waiting, and more time transmitting. Let's upgrade this protocol:
Host - "Device, send sectors 1 to 100000"
In this case, the device will try to push data through the channel for the entire read range at maximum throughput, without having to wait for a new command after each sector.
An even more efficient protocol would use Command Queuing (like SATA NCQ) to reduce latency even more.
This explains the difference in benchmarks between random reads and sequential reads for example.