That's actually the wrong way round. For advanced designs the instruction set really doesn't matter that much, the bulk of the silicon in a modern advanced CPU

That's actually the wrong way round. For advanced designs the instruction set really doesn't matter that much, the bulk of the silicon in a modern advanced CPU is spent doing things like caching, branch prediction, instruction scheduling, buffering loads and stores that may be unwound due to speculation, address translation, etc. These things are completely instruction set agnostic. To see how little it matters look how well x86 processors work despite the x86 instruction set being a mess (even figuring out how long an instruction is in bytes is a nightmare) or how well advanced ARMv7 processors despite that instruction set being a mess (a free shift on every immediate, urgh). Now low-power is a completely different game. The bulk of the CPU is spent doing really quite basic stuff, fetching instructions, decoding instructions, simple ALU ops. Tiny differences to the instruction set can make a big difference to how much silicon (thus power) this takes. This is why RISC-V offers a 'reduced' variant (with only 16 registers), they know that for any low-power design the vast majority of silicon area is just going to be spent on flip-flops or latches for the 32 entry register file (what a waste given the tiny performance bump in moving from 16 to 32 registers). That's a lot of leakage power for no reason. Now RISC-V is not necessarily a great instruction set, but it's not really an awful instruction set either (from a pure perspective of implementing an efficient 32-bit CPU, I'm sure it has academic advantages). For example nobody implements a RISC-V CPU without the 'C' extension (16-bit instructions) and given that they really should have just made all instructions 16-bit with optional 16-bit or 32-bit payloads (typically immediates). This would have meant it was only a single instruction to load a 32-bit constant rather than two and code density would be higher (thus less power spent fetching and decoding instructions). On the other hand you'd have a lot less extensibility available. Probably this would require 16 registers instead of 32 (not enough bits in the 16-bit instructions otherwise), but again this is a good thing for lower power in small CPUs. So RISC-V will never be the best instruction set for low-power 32-bit CPUs, but it's definitely better than x86 and ARMv7, and that's probably enough. And for 'advanced' designs it just doesn't matter, it's all about the quality of the implementation. Personally I dislike RISC-V but I will still use it for implementing CPUs (and already have) due to the toolchain support. Designing your own instruction set is fun but porting a compiler is not, and RISC-V is sufficiently 'not bad' that it does the job. I imagine a lot of people feel similarly.