Exactly that - they specify things that you need for an OS on a desktop/server system but complete overkill for embedded applications. I think the goal was to have one version of "RISC-V Linux" without vendor-specific extensions, but the chip vendors are used to their extensions, and there are good reasons to allow them to have some more customization (to allow design tradeoffs).
Also, in the ARM ecosystem, some of the things that the RISC-V spec specifies (like MMU details) are vendor-specific, leading to a minor headache for OS writers, but give chip manufacturers more freedom. Renesas may have assumed they had the same freedom.
The Arm ecosystem is a shitshow for this reason, with massive efforts required to port to each new SBC. We hope to standardize RISC-V enough to avoid at least the worst of this (Linux drivers will still be a problem, but you should be able to boot a standard single image on most boards even if some of the hardware won't always work at the start).
So this sounds like a deliberate design choice. Like when Intel went from pins to balls shifting the complexity to the motherboard. There are always trade-offs. I guess the idea is that the overhead is worth the benefit to the ecosystem and if the vendor really needs to they can create a chip that is only conformant at a user level but not at a priveledged level and still better than starting a custom ISA from scratch.
Also, in the ARM ecosystem, some of the things that the RISC-V spec specifies (like MMU details) are vendor-specific, leading to a minor headache for OS writers, but give chip manufacturers more freedom. Renesas may have assumed they had the same freedom.