HN's obsession with RISC-V code density reminds me of the 1980's and the first heyday of RISC architectures (SPARC, MIPS, HP-PA, POWER, and later Alpha).
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.
Note that the article is specifically about the SEGGER toolchain, not to be confused with GNU's or LLVM.
Personally, I won't use a toolchain that isn't open source, so I can't care less about how bad SEGGER is at producing dense RISC-V code.
As for the actual facts, 32-bit RISC-V is very dense, but Thumb2 was better at some point. It is indeed still better than ratified spec, but watch out for Zc and B extensions.
Last time I checked, 32bit RISC-V was already more dense than Thumb2 with these extensions.
In 64bit, RISC-V has held the code density crown for a long time now. Wins by a wide margin. There's no contest. And it is indeed also getting even better from these extensions.