PCIe on an ARM-based system is not exceptional. SBCs have been doing it for years, it's just generally avoided due to being a designed-for-desktop standard with high power limits and a unique physical layer. SDIO, SPI, and I²C tend to be preferred

8 feet away from me is a cheap Pi-like with a high-end PCIe NVMe slotted into it. it doesn't run full speed, but 2 lanes of PCIe 2.0 is more than enough for my purposes

to put "high power limits" in perspective, the maximum from-slot power draw on a PCIe slot ranges from 10W (1x) to 75W (16x)

the maximum power draw of the entire SBC is a mere 15W, limited by its 5V3A power supply. it cannot power a full-fat PCIe device, not even getting into the fact it has no 12V rail

however, with the required power supply circuitry (like would be found in a laptop) this barebones implementation of PCIe data is easily upgraded to the real deal

NVMes, SATA controllers, and a lot of other smaller add-in cards don't need or want 12V so they work fine here, hence my SBC having NVMe storage in it

for a PCIe device that does not use 12V, the maximum power draw is still relatively huge — 10W. despite this, I can run the CPU, GPU, radios, and NVMe all at full tilt and it doesn't overload the power supply. the NVMe just doesn't need that much power

anyway, the point is: PCIe-compatible ARM SOCs have existed for quite a while, the only limiting factor for providing true PCIe is power. ARM SOCs are usually made for phones, so yeah.

Apple is providing an ARM SOC with PCIe support alongside a full power supply system. they haven't solved some magic problem that makes PCIe and ARM incompatible, PCIe is a fairly universal standard. the only reason PCIe isn't common on ARM is that people just don't tend to want it.

as we see more and more laptop- and even desktop-grade ARM SOCs, this will only become more common