I don't see how "wild" it is. RISC-V was designed as a general-purpose, extensible ISA. Apart from the core functions, everything was left as future extensions. And that's part of its strength.
Of course, it also leads to fragmentation, but that's unavoidable.
If we nitpick, "x86" CPUs are also heavily fragmented, in that each new generation has added a large number of new instructions and features. So if you stick to the least common denominator, you're left with, not that much actually.
The NVIC example is interesting and ill-positioned: indeed; the NVIC controller is only available on Cortex-M cores (so, in short, MCUs), while Cortex-A cores have a different interrupt controller. So there's also "fragmentation" even in the ARM world.
Sure, those who are only interested in RISC-V MCUs for now may throw a tantrum, because it's fragmented even in this "niche". But that comes with openness and its relative youth. When CLIC is ratified, sure vendors are likely to adopt it, but still, some may add particular features to gain a competitive advantage, that may require specific, non-standard support. And that's good. I like having options.
The fact that a given different implementation of an interrupt controller may impact compilers or not is another story. Not all implementations require anything more than the basic "interrupt" behavior of GCC/Clang. And here, once this register saving thing is settled (which will be generic enough to accomodate pretty much all cases), the rest will only require accessing some CSRs and memory-mapped registers, so there shouldn't be any more vendor-specific support required in compilers.