So I've taken a quick look at RISC-V's spec.
It should be possible to use only the "C" extension 16-bit encoding. All ALU functions are available, ADD, SUB, AND, OR, XOR, various shifts, along with load/store, and branching. There would be limitations for offsets, but nothing that can't be addressed (no pun intended) by using multiple/indirect loads. The other big issue is that we would be limited to 8 registers, notably the ALU instructions can access only 8 registers. However, x86 long lived with only 7 (user visible) general purpose registers.
The 2 big issues are rather that it would be 1) non standard (RV32E mandates 16 registers, we would be limited to 8 here). And 2) the compilers would have to be modified to generate that non-standard 8 registers limited 16-bit C encodings. So, not trivial, but no huge difficulties.
The big question would be: is it worth it?
As already mentioned, with current silicon technologies, probably not (compared to RV32E we would "only" save 8x32-bit regs area + the 32-bit instruction decoder area).
As an old timer (Zilog Z80 or 6502 8-bit CPU + 64K RAM), I always find it weird to have 32-bit registers for "modern" microcontrollers:
https://www.silabs.com/mcu/32-bit-microcontrollers/efm32-zero-gecko (ARM M0+ with 4K RAM and 32K ROM (flash)). In fact, there is already one such RISC-V processor with internal 16-bit datapath, named RV16:
https://link.springer.com/article/10.1007/s11390-022-0910-x (the pdf is freely viewable on chinese institute which designed the chip).
My guess is that a clean sheet design looking for the absolute minimum in power consumption and area, that should be considered.
Otherwise, the "niche" of integrated small microcontroller for FPGAs, is probably the best target. In fact, there's already such a proof of concept:
https://github.com/AntonMause/rv16poc