Ease of decode - You want your instruction stream to be dense to fit easily in I-cache. You want it to be self-synchronizing for easy multiple decode. You want the input registers to be at predictable offsets from the instruction start to speed up fetching them.

Data Dependancies - The design of your OoO execution engine will depend on the maximum number of outputs and especially inputs an instruction can have. Flags are inputs too. If some instructions can only partially update your flags (like x86) then the flags count as multiple inputs now.

Atomic execution - Handling precise exceptions from timer interrupts or page faults or whatever mean you have to go back to some coherent state. This is easier if your instructions only touch memory at most once each. Especially difficult is multiple writes to memory in an instruction but read-modify-write is also bad. Read-modify and modify-write are pretty ok but still add a bit of complexity.

And one can argue about whether it's better to have 16 or 32 registers but with x86-64 everybody these days has one of those and is good enough. Well, actually SPARC with its register windows has way more than 32 and that might be Fujitsu's biggest motivation in moving to ARM.