It's more that the GPIO interface on Linux is very heavy weight as it's a sysfs interface to perform any signal transitions, and exposes only a lowest common denominator of function composibility. That eats a ton of cycles.
Like, yeah, twiddling a GPIO line is more expensive than you'd think on an RPi. It's in the dozens of cycles range. But if you look at it in terms of wall time, single cycle access on an Arduino is 62.5ns, and each cycle on an RPi at 900Mhz is 1.1ns, so they're in the same ballpark if you have bare metal access.
The sentence just prior I stated that it was dozens of CPU cycles to access GPIO blocks. Your citation is consistent with my statements.
And BTW, the problem isn't slow clocking from the GPIO. It runs at about half CPU clock depending on the RPi model, which doesn't account for the latency you're seeing. It's actually spending most of the time simply propagating unchached accesses across the fabric, taking a long time for the same reason that an uncached read from DRAM takes a lot of cycles.
But at the end of the day, my whole argument was that the hardware is capable of about equivalent to an Arduino in terms of wiggling lines. However, from Linux you can't consistently meet deadlines without writing a kernel module because of the IPIs the kernel uses internally for bookkeeping. At that point you're comparing the developer UX between writing a kernel module with that of an Arduino sketch, and there's a pretty clear winner for productivity. That's why I welcome alternative software stacks.
Like, yeah, twiddling a GPIO line is more expensive than you'd think on an RPi. It's in the dozens of cycles range. But if you look at it in terms of wall time, single cycle access on an Arduino is 62.5ns, and each cycle on an RPi at 900Mhz is 1.1ns, so they're in the same ballpark if you have bare metal access.