Mind you that raw core performance is not everything, memory bandwidth and caches are crucial to make sure the CPU isn't waiting for data all the time.
I trust that the Apple benchmarks include all such effects. I'm less convinced that the RISC-V "projections" include them. SPECint2006 is supposed to be measured with real memory and an OS. Per-GHz numbers can't accurately reflect main memory latency, since its speed doesn't scale with the CPU clock.
Right, and "per GHz" numbers are also not very useful because you can't just crank up the GHz when you need performance. Even with the same process technology, you can't assume different microarchitectures will max out at the same frequency.
You're right, and remarkably Apple has found a major roadblock to clock speeds while using ARMv8.
M1's L1 cache is huge, as a workaround to ARMv8's poor code density. Larger cache means lower clocks, unfortunately there's no way around speed of light.
How impressive that number is rather depends on how many GHz they're managing. In general the slower you design your clock to clock, the faster you can make all your caches. Plus the slower you clock your core, designed in or not, the lower the number of clock cycles it takes to talk to main memory.
11+ SPECInt2006/GHz is comparable to Apple Icestorm microarchitecture. Apple Firestorm microarchitecture is roughly 2x better at 22 SPECInt2006/GHz.