I noticed that RISC-V, like some other RISC architectures, by convention treats register 1 specially, using it as the link register, holding the return address for function calls.
If most code follows this convention, since instructions are aligned to 4 bytes, then r1 will follow that alignment, so the lower two bits will be predictably zero, and could be hardwired to zero, saving a few transistors. (Admittedly a tiny saving on the scale of today's chips, but it makes a good concrete example.)
But of course this is only a convention. r1 can be used otherwise; as far as the hardware is concerned, it is a general-purpose register. That doesn't mean code is particularly likely to need to treat it as a general register with all 32 bits available (since there are thirty other registers that can be used that way), but it does mean in an out of order implementation, it participates in register renaming.
When the register renaming circuitry is mapping architectural registers to a larger number of physical registers, would the existence of special registers complicate things? For example, had the architecture been defined so that the low two bits of r1 were hardwired to zero, would an out of order implementation then have an extra complication of having to track the fact that such and such a particular physical register is actually a renaming of that special register, so as to be ready to throw away any 1's that an operation might try to write into those low two bits?
Or, more generally: once CPUs start going out of order, if some registers are treated specially, does the hardware then start needing extra logic gates to keep track of which registers are renamed from the special ones?