Seeing a graphical library being a part of the benchmark, it reminded me of the Acorn Risc Machine origins: a graphical workstation in which the processor does the bitmapping. Naturally Thumb2, as a descendant, would be strong here, and those instructions also work out for crypto.
My second point would be, as you imply, that RISCV has a mostly unused code space, which could be filled in to make it more performant. To make it comparable to thumb2 that would mean adding bit-shifting instructions, notably lacking from RISCV, like the ARM has. Your comment is spot on.
Third, at best this is a benchmark for high-end embedded systems, not what I would call embedded, a market which would be better served with a genuine operating system, if not for the power requirements that would entail.
Lastly, there's competition for their benchmark in the form of a RISC-V backed initiative, by the same name, targeting embedded, quoting:
"Dhrystone and Coremark have been the defacto standard microcontroller benchmark suites for the last thirty years, but these benchmarks no longer reflect the needs of modern embedded systems. Embench™ was explicitly designed to meet the requirements of modern connected embedded systems. The benchmarks are free, relevant, portable, and well implemented"
That benchmark puts thumb at a 7% advantage: https://youtu.be/xX0krFFvlUM?t=1200, but is comparing to a slightly extended RV32IMC.
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.