> power need[s] to be exploited locally

Not in the presence of DVFS, it turns out: https://www.hertzbleed.com/hertzbleed.pdf

It depends.

AES cache-timing was broken over a network (but required, like, 2^28 samples).

I wouldn't bet the farm on this line of thinking providing resilience. It might be just annoying enough for an attacker to not really bother. (Or maybe only if the target is, like, a software cryptocurrency wallet with enough value to loot if they're successful.)

Cache and power are shared resources, not just timing observations. High-assurance security always advised physical separation as much as possible to avoid timing channels. So, you'd run them on different boards, flush the caches, or make power invisible to untrusted applications. They also used to modify the granularity of visible timing or use logical time to prevent the measurements from happening.

Recently, people have come up with partitioned caches to deal with this. I don't know if they exist in production. A simple strategy is turning off shared caches while running processes of different, security levels on their own cores. Also, investing in multi-core and many-core architectures for this.

Finally, many of us pushed for randomized execution or scheduling to throw off the timing of specific things. Combined with fine-grained processes (eg separation kernels), that should reduce what they can do a lot.