My RISC-V experience is all based around the low-end (no MMUs, hypervisors, indeed mostly no caches) so it's hard for me to give a full informed comparison but my feeling is the Arm ISA is better specified and RISC-V won't necessarily be a simpler architecture in the end anyway. There is an explosion of extensions in RISC-V right now, lots of tiny ones along with some bigger ones. Whilst the size of the ISA manual between the two is often highlighted (the Arm architecture reference manual is almost 13'000 pages in the PDF I just downloaded) those pages are there for reason. It's no surprise now there are multiple well-funded startups trying to build high end RISC-V cores that there's also a massive push to add a lot more stuff to the RISC-V architecture.

My feeling, as it's a bunch of different companies all with a commercial pressure to get things shipped, is we'll end up in a rather chaotic place with the RISC-V ISA, though hopefully that can be improved with time.

I do get frustrated with the loose specification of the RISC-V ISA. The Arm ARM for instance has a precise description of its exception model (see section D1.3 'Exceptions') the RISC-V ISA in contrast never explicitly defines what an exception is and to find out what the exception model is you need to read through the definitions of a few system CSRs (control and status registers) and join the dots yourself. It's seemingly written with the idea that everyone knows what an exception is in the context of computer architecture so no need to give a long formal definition, plus everyone will agree on what the 'obvious' right answer is where the spec isn't precise. However the devil, as ever, is in the details and the details are often lacking.

I also note there's no complete RISC-V conformance test suite and indeed even building such a thing could be intractable look at PMP, physical memory protection, you could do all kinds of odd implementations of this that would be spec compliant (e.g. only region 12 is allowed to have execute permissions set and cannot be read/write/execute) but would be a total nightmare to support in a conformance test suite. So such a suite, when it does hopefully emerge, will actually only conform compliance with a subset of compliant CPUs. There are some obvious stupid design decisions it's reasonable to rule out but I'm sure there will be some other less clear cut things where the spec allows multiple behaviours, the compliance suite will only work with one or two and they'll be some shipping implementation which went with another one. People will either spend lots of time arguing about how the compliance suite should work, or just ignore it altogether. A lot of these difficulties stem from the loose specification of RISC-V.