I think that hardware factors like those are generally irrelevant when it comes to purely software issues, like we're discussing here. In this case, we're talking about an energy consumption penalty imposed solely at the software layer.

Aside from arguments about the screen perhaps not needing to be used as long when the software completes its operations faster, I think it's probably safe to say that such hardware-specific energy consumption due to the factors you mention would be constant in both the case of compiled applications and the case of interpreted applications.

Good point. A better argument against the interpreted approach is that interpreted languages to a larger degree tend to be rather dynamic. With a platform like iOS where release cycles are fairly lengthy(not that this is really Warranted IMO) a static language is much more sensible. It's obviously a lot better to find as many bugs as possible before shipping and I would argue that this is much easier in stricter static languages. Frontend javascript for example is fine being dynamic and interpreted because it's easy to hotfix issues

The reason the CPU is not using most of the energy is because it's not used all the time. And that's by design. Every single thing possible under the sun is done to keep the CPU off for even a split ms on mobile.

Because if you start using the CPU all the time, your battery is done.