Apple don't publish much details of the core - most of what we know is intuited from benchmarking.
Yes, but decode is what we're talking about.
uOp cache is clever, but as any cache it is costly (power, area) and necessary only because x86 decode is very hard.
You can argue about the cost of the uOp cache being expensive, but it's disingenuous to ignore it.
Yes, modern x86 are wide from the uop cache, but this cache is made of simple, easy to process uop and not native instructions. The native part is still "only" 4 wide. The whole existence of the uop cache is to avoid repetitive native instructions decoding and replace it by dealing with simple uop. That's because this native x86 decoding is expensive and hard to widen, which is exactly GP's point.
You're saying the uop cache makes this a non issue in practice: maybe (cost/efficiency of this cache vs a simpler design? I don't know ;), but that was not the point GP was discussing. The point was only that the C extension is easy to decode, with as practical proof the width of existing implementations supporting it.