I'm no processor designer, but here's what I'm thinking, as I look at how the op codes are arranged on the table. See if this reasoning has merit.
Consider all the op codes that have Y as the destination register for example:
Code:
PLY 0111 1010
LDY# 1010 0000
LDY_ABS 1010 1100
LDY_ZP,X 1011 0100
LDY_ABS,X 1011 1100
TAY 1010 1000
INY 1100 1000
DEY 1000 1000
The only bit that's consistent is bit 0; but there are a lot of other op codes that have the same value in bit 0 that don't have Y as a destination for putting results, so other bits have to be inverted, ANDed, etc. for the instruction decoder to figure it out. (It does look like it was easier before PLY came along on the CMOS 6502; but that instruction is rather valuable.)
I would think that if you have enough bits, one bit could always be used to say the destination register is Y, without having to examine other bits, another could be used to mean the destination register is A, or stack, or other memory, etc., and you could even load more than one register at once if you wanted to, like some programs have LDY#0 and LDX#0, or LDY#FF and LDX#FF, right together. Another bit could indicate a source, or a particular step in the address mode, or a particular step in ALU usage, without having to examine any other bits. In fact with enough op code bits, the instruction decoder might be reduced to almost nothing, and the various fields in the op code itself would direct traffic throughout the various cycles of an instruction.
Even if it did not speed anything up, it may reduce the FPGA resources needed, allowing more instructions, register width, or whatever, in a given size of FPGA.