I think an example is something like opcodes crossing I-cache lines, re: fetch and decode complication; instructions are 16-bit aligned when C is present, so you can have a 32-byte instruction cross cache lines easily. At minimum it will definitely require a bunch of extra verification to handle those cases, and that's often the longest part of the whole development process anyway, so I see the reasoning for not wanting it. It doesn't matter how high performance something is or can be, if you can't prove it works to some tolerance level.

I know there's the big discussion about macro-op fusion. But in hindsight, I think a big motivator for C -- implicit or not -- was the fact that on the very low-end microcontroller or in the softcore (FPGA) world, you typically have disproportionately low amounts of SRAM available versus compute fabric. Those were the initial deployment targets (and initial successful deployments!) for RISC-V, since you need tons of extra features for "Application Class" designs. These cores often have a short pipeline and are completely in-order, so their cost and verification effort are much lower. These are (very likely) not going to implement macro fusion, at least on the medium-low end. So, increasing the effective size of the I-cache through smaller opcodes is often a straight win to increase IPC. On the other hand, Application Class designs today are typically OoO, so they achieve high IPC while still hiding miss latencies pretty effectively; smaller instructions are still good but the benefits they provide aren't as prominent. And it does use a ridiculous amount of opcode space, yes.

I wonder if they would have just been better off copying one of ARM's design principles from the very start: actual design families akin to the -M, -R, and -A series of ARM processors, created for different actual design spaces. These could actually be allowed to have (potentially large!) incompatibilities between them while still sharing a lot of the base instruction set and privileged e.g. PMP extensions could probably exist among all of them. I'd be happy to have an "Application Class" "-A series" RISC-V processor that could run Linux but didn't have compressed instructions or whatever; likewise I would probably not miss e.g. Hypervisor extensions on a microcontroller.

EDIT: Clipped an incorrect bit about ABI compatibility with the C extension. I was misremembering some details about a specific implementation!