It's because then the other fields, such as the source and destination registers can stay in the same place across various opcodes. In the rare cases there's an immediate field, such as the jump offset, it uses what would otherwise be a register or an operand.
Disassembling RISC-V is then quite straightforward because of this feature.
As someone who's written a lot of disassemblers, this feature is far more complicated to write a disassembler for than how the other RISCs handle it, by close to an order of magnitude when you account for the extra tests that you want too.
All of the bits being contiguous would just mean that you could just
jump_offset = (((i32)opcode) & 0xFFFFF000) >> 12;
rather than this weird game of trying to piecemeal back all of the requisite components. Or, if the components are in order then you're given the choice; it doesn't have to be a mutually exclusive decision.
It's got to be saving some muxes on tiny cores by keeping the sign bit and bits 10:5 in the same place, but honestly even that seems like a micro optimization that doesn't have a lot of benefit at the end of the day. I wouldn't think that this single saved mux would have been in a critical path (and the sign bit would have been in the same place regardless).
Disassembling RISC-V is then quite straightforward because of this feature.