That's a big part of it. I remember in the Early Pentium 4 days, starting to see a lot more visible 'squiggles' on PCB traces on motherboards; the squiggles essentially being a case of 'these lines need more length to be about as long as the other lines and not skew timing'
In the case of what the article is describing, I'm imagining a sort of 'harness cable' that has a connector on each end for all the fibers, and the fibers in the cable itself are all the same length, there wouldn't be a skew timing issue. (Instead, you worry about bend radius limitations.)
> Would the SerDes be the new bottleneck in the approach
I'd think yes, but at the same time in my head I can't really decide whether it's a harder problem than normal mux/demux.
Things get interesting if the losses are high and there needs to be a DFE. This limits speed a lot, but then copper solutions moved to sending multi-bit symbols (PAM 3, 4,5,6,8,16.. ) which can also be done in optical domain. One can even send multiple wavelengths in optical domain, so there are ways to boost the baud rate without requiring high clock frequencies.
Semi-accurate. For example, PCIe remains dominant in computing. PCIe is technically a serial protocol, as new versions of PCIe (7.0 is releasing soon) increase the serial transmission rate. However, PCIe is also parallel-wise scalable based on performance needs through "lanes", where one lane is a total of four wires, arranged as two differential pairs, with one pair for receiving (RX) and one for transmitting (TX).
PCIe scales up to 16 lanes, so a PCIe x16 interface will have 64 wires forming 32 differential pairs. When routing PCIe traces, the length of all differential pairs must be within <100 mils of each other (I believe; it's been about 10 years since I last read the spec). That's to address the "timing skew between lanes" you mention, and DRCs in the PCB design software will ensure the trace length skew requirement is respected.
>how can this be addressed in this massive parallel optical parallel interface?
From a hardware perspective, reserve a few "pixels" of the story's MicroLED transmitter array for link control, not for data transfer. Examples might be a clock or a data frame synchronization signal. From the software side, design a communication protocol which negotiates a stable connection between the endpoints and incorporates checksums.
Abstractly, the serial vs. parallel dynamic shifts as technology advances. Raising clock rates to shove more data down the line faster (serial improvement) works to a point, but you'll eventually hit the limits of your current technology. Still need more bandwidth? Just add more lines to meet your needs (parallel improvement). Eventually the technology improves, and the dynamic continues. A perfect example of that is PCIe.