It means that in the end, maintaining duplicated assembly code paths for different ISAs would have been cheaper and much easier than the absurdely complex linux+gcc(or clang) duo. And I could bet than some code paths could be kept in simple and plain C (compiling with _not_ only gcc/clang) without that much loss of performance.
Erm. So that's a language/compiler issue, nothing to do with the ISA? And I might be on board with embedding assembly, but AFAIK that also requires compiler extensions. And I'm not an expert on compilers or C, but I suspect that still doesn't cover all the uses of compiler extensions.
Since RISC-V should be an international standard for assembly level interoperability, that removes in a reasonable way this "compiler/language" issue ... until no technically very expensive code generators/code preprocessors are used since those would not be that less worse than an optimizing compiler.
Write RISC-V assembly once, run anywhere.
The cherry on top, RISC-V ISAs do not have toxic IP tied to them, like x86_64 or ARM, and that at a worldwide level.
I would be ready to pay the price of losing some speed on C code paths until I can compile them with "toy"/small/alternative compilers which are not gcc/clang, BUT I cannot even do that since linux code is hard dependent on gcc extensions.
All that is a very strong case for RISC-V.