I don't agree with the argument.

By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.

And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns.

Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed.

RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space.

Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)

Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated).

I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.