<i>ARM has never enjoyed a Op/J advantage over x86.</i>

I'm not sure that exactly accurate, its more accurate to say, that there was a lack of market crossover that allowed similar power or perf envelopes.

That is because ARM did/does make much more efficient CPU's, they just aren't anywhere close to the perf of common x86 cores. AKA a low clocked in order ARM with small caches, etc is more efficient per op but it can't touch even a medium size x86. Intel sort of was in that market for a bit and their cores were efficient too, but the main selling point for an architecture is the software around it, and a 50 mhz in-order x86 can't exactly run modern windows in a reasonable way.

Now that ARM & friends are building higher perf parts, the power efficiency keeps getting worse. When someone makes a 5Ghz ARM core it will likely consume more than a couple mW.

The perf/power ratios have more to do with culture and market than ISA.

I suspect that, at least for lower-power or lower-area designs, a compact ISA with a friendlier encoding than x86 would be a win. A significant problem with x86 is that a high-performance core needs to decode multiple instructions per cycle, but x86 has a nasty problem that the length of an instruction can’t be determined until it’s fully decoded. I think that modern front-ends try all possible offsets at once and throw out the wrong guesses. This costs area and power.

A design where all instructions have one of just a few sizes and where the first byte unambiguously encodes the length would be nicer.

RISV-V is decent in this respect.

FWIW, x86’s legacy is a security problem, too. The ISA is so overcomplicated that nasty interactions cause all manner of security bugs. As a recent example, the sequence mov (ptr), %ss; syscall with a data breakpoint at ptr could be used to root most kernels. With virtualization, this type of thing is much worse. A hypervisor needs to handle all the nasty corner cases in a guest user program without crashing itself or the guest kernel, and it needs to handle all the nasty corner cases in guest kernels without dying. There are various ways that native kernels can literally put the microcode in an infinite loop, and hypervisors need complex mitigations because an infinite-looping microcode bug triggered by a guest can’t be preempted by the host, and it will take down the system.

So yes, x86 is not fantastic.

Can you provide a link to the infinite-loop microcode issue?

One of them: https://xenbits.xen.org/xsa/advisory-156.html

I had assumed the opposite, that ARM was better in terms of Op/J. Can you provide a reference to make it certain?

Also, I wonder if the low density of RISC could be countered by introducing execution of compressed/zipped machine code. Some compressors like brotli are highly tuned to the expected type of data to be compressed and are very compact. All entry points to basic blocks in the code are generally known at compile time, so it can be ensured that the jump destinations are decompressible without any context, avoiding the slow process of needing to scan backwards to start decompressing...

Arm Thumb is a compressed ISA. Intel has been decompressing x86 instructions into an internal RISC machine since the Pentium Pro. The benefit is getting more instructions through the chokepoint from DRAM to L1 cache.

The Apple arm chips are way more efficient than any x86. They have comparable performance with a much, much lower power requirement.

The writing was on the wall in the early 90s. The SuperH ISA basically gave you the best of both world's: Fixed-width, relatively easy to decode instructions that were 16-bit, rather than 32 bits of many RISC ISAs.