What does clock/signal speed actually do?
The clock speed (well, data rate) that a wire can carry is limited ultimately by its bandwidth and the presence of noise. This is formalized in Shannon’s Information Theory.
Some light reading here: https://www.scientificamerican.com/article/claude-e-shannon-founder/
Anyway, the data rate chosen depends on the needs of the application.
I2C is designed to be low cost, highly compatible as a shared bus, and somewhat tolerant of poor signal integrity: slow rise times, reflections and system noise, and the fact that it only uses two wires. Even within I2C, there are additional signal integrity considerations that arise with the faster modes.
Notably, I2C doesn’t treat wires as transmission lines, but as lumped RC networks. The rise and fall time are determined by the trace capacitance and pull-up resistor and open-collector drive strength.
Faster buses do treat wires as transmission lines with a characteristic impedance. When you think of signals flying ‘near the speed of light’ you’re thinking of a transmission line. In fact any wire is a transmission line, but to do a good job as one it must be designed with good signal integrity (consistent impedance, proper termination, reasonable inductance and capacitance per unit length) and have the electronics matched to it.
So the RMII bus (Ethernet MAC - PHY connection) 50MHz demands more care in layout, and is also point-to-point. It’s limited by the delay from the main clock launch to the returning data from the far end: turn-around time. RGMII overcomes this with source-synchronous clocks so it can run at 125MHz.
Normal SPI has the same issue: turn-around time limits read cycle time. Nevertheless it is normally rated for up to 108MHz, which is achievable with careful design and fast drivers.
There’s even faster SPI variants that adopt a kind of source-sync clock. These go up to 200MHz. SPI descendant Hyperbus can do 400MHz double-data rate.
So the takeaway is, clock speed depends on the transmission medium as the ultimate limit, followed by limits imposed by what you need, how much design effort you’re willing to invest, and how much you’re willing to spend on hardware to meet your need.