Nope, I'm not assuming that in the slightest. In fact, I'm assuming exactly what you're assuming -- some fraction of time way less than 50% spent running emulated code. I'm also coming to the same conclusion you are -- that emulation of legacy x86 code with Good Enough performance could be used as a bridge off of x86. Reread the post.

But let me address this specifically:

"It's the 20% case, and if that 20% uses as much (or even more) power as a native Intel device, that's perfectly acceptable."

There's no need to speculate, here: the emulated code either will use significantly more power, or it will perform significantly worse.

In fact, as for the native ARM code on the ARM chip, it also will either use more power or perform worse than comparable x86 code running natively on an Intel chip within the same power envelope, because Intel has thrown a massive amount of engineering at their microarchitectures and manufacturing process, they have vertical integration that they can use to their advantage, and their stuff is just very good.

Again, there are no magical ARM performance elves lurking under the hood -- the ARM ISA by itself doesn't confer any real advantages in performance (and hence performance/watt) in the billion+ transistor regime. I truly don't understand why this is so hard for people to accept, but I blame Apple for spreading years of FUD about x86 (before bailing on "RISC" for it, of course).

Back to the topic of the emulated code, though: I can't say is whether "significantly worse" or "significantly more power" will still be Good Enough, but I'm assuming it will for most apps people care about.