Haswell is a much narrower architecture than A14 though - 4-wide decode vs 8-wide for Firestorm. So it's 3-10% for an implementation that does significantly less than Apple's. And the problem is that x86 has geometric complexity as you go wider, so it consumes significantly more if you want to go as wide as Apple did.

You're saying "nothing wrong with an n^2 algorithm, it works fine for us with n=1000", when you're comparing against someone who is showing results for n=1M. Obviously it would be better for someone in the latter situation to use an n-log-n algorithm. Not real numbers or transistor order-complexities, but you get the idea, x86 has asymptotically worse transistor complexity than ARM as you increase the decode width, and that is true.

Also, that number is for a full-fat Performance Core. If the rest of the core shrinks, the decoder gets relatively bigger, unless you reduce its performance too. So the amount of decoder area (as a % of the overall core) is worse on efficiency cores than performance cores, because there's less "everything else" there.

(likely you will reduce the decoder somewhat, Goldmont and Gracemont both use a 3-wide instead of 4-wide, but geometric scaling means that it's much more expensive to scale wider than you would save from scaling down. And the reliance on 'tricks' like instruction cache likely won't scale nearly as well - it's the same amount of "hot code" for many tasks, regardless of how many threads are running in it, because most of the work happens in certain hotspots. The increased overhead of decoding could, among other factors, be one of the reasons why Gracemont e-cores are not particularly appealing in perf/area. They are very solid on performance but the area scaling isn't all that great compared to hyperthreaded Golden Cove Performance Cores.)

Also that's really just looking at one part of the processor in isolation. OK, so the decoder only consumes 3-10%, but that doesn't say anything about how it limits the ways the rest of the processor to scale. Everyone loves car analogies, it doesn't matter how big an engine you put in the car if it has a rinky-dink air intake that can't provide enough air to fully utilize its displacement. Looking at "the size of the air intake relative to the size of the engine bay" doesn't give you a realistic picture of how it affects the ability of the rest of the design to scale. A turbo might allow you to scale the rest of the engine up much larger than a naturally aspirated one.

(or maybe the fuel system might be a better analogy...)

As far as the instruction cache - those are tricks can be used on ARM architectures too (and I believe Apple does?), they aren't themselves a substitute for a scalable ISA, they're treating the symptom. They may do more on an architecture that is more bottlenecked in that area, but they do give you at least some speedup on everything. Treating the symptoms is really orthogonal to the topic of how much an ISA limits decoding width or reorder depth in itself.

Anyway, x86 isn't Itanium and it isn't going anywhere, but it strongly looks to me like ARMv8 is on a solid foundation that solves some weaknesses of the x86 design. It's a clean-sheet "how would we do out-of-order/speculation if we could design our instructions over again" and it largely achieves that goal IMO. I don't see it as an inherent law of the universe that "there must exist enough tricks for x86 to match the performance of any competitor". There's always lots of metrics to look at, and in many cases Apple is designing for fundamentally different metrics than AMD/Intel, but I don't quite get the reluctance people have to admit that ARM is going to be better than x86 in some of those metrics, even on iso-node (like A15 vs Zen4). And this is like, the core metric that aarch64 was designed around.