One of the main reasons for making mtime/mtimecmp memory-mapped rather than CSRs is to support systems where the CPU(s) do not run at a constant clock frequency.  In such systems, the mtime counter must reside in a different clock domain (and often voltage domain) from the CPU.  If the *timecmp registers are implemented as CSRs, the 64-bit compare value must be passed from the CPU clock domain to the mtime clock domain, which is a costly overhead for the CPU design.  (The alternative of passing the mtime value into the CPU clock domain is much worse for power, since it changes much more frequently than the compare value.)

Another alternative is for the CPU to translate the CSR write instruction into a memory write.  This is impractical for a CPU IP, because the CPU designers do not know the SoC memory map (which might vary between implementations/customers, or even be programmable at runtime).  There is also the overhead of handling interactions with PMP/PMA, etc.

How feasible is it to generate timer-interrupts for VS-mode software from a counter in the CPU clock domain?  The hypervisor could apply an appropriate scaling factor to align with wall-clock time, perhaps using an htimescale register somewhat analogous to htimedelta.