Especially because code density ends up limiting the speed one can get out of a design, given a memory bandwidth bottleneck. So one might expect RISCV to outpace all other architectures once a neat set of extensions has been worked out. Indeed that needs a frustrating bit of time.
However, you do sound like a self-righteous OpenSource "customer" who can only spitefully complain about a product that he didn't lift a finger to help deliver. That of course describes wrong doing, only somewhat understandable because we similarly inherited a world to live in, comparable to that open source product, and it isn't up to standard, if ever, and democracy doesn't allow us to make the changes we would like, to make it less of a bitch.
I don't understand your final paragraph even a little bit. It's a bit odd.
Higher code density means higher likeliness that performance-critical code will fit in L1$.
End users don't care at all about code density. If their application runs faster, that chip is what they'll want. (Compare a DECstation with a MIPS CPU to a VAXstation of the same era to get an idea.)
We don't have high-performance implementations of RISC-V yet, though, so these debates can go on and on. I'm looking forward to seeing actual high performance implementations from Tenstorrent and others, so there's something concrete to discuss.