Only 1 operand byte. The VEX and EVEX prefixes replace the 0f/0f38/0f3a opcode prefixes with an opcode map selector, and the 66/f2/f3 prefixes are also shoved into some more bits in the prefix. The only prefixes not subsumed by the EVEX prefix are F0 (largely lock), the segment selectors, and the address size override prefix... the last of which should never be used in 64-bit code anyways, and the former are pretty rare in instructions.
If you've got a 3-byte opcode that needs the REX prefix, you're going from 5 byte encoding to 6-byte encoding, which isn't too bad, but it is going to hurt for those instructions that previously could get away with 2 bytes.
The extra 16 registers are going to be a lot more fun though. It will also eliminate a lot of those MOVs, but every access will have a 17% penalty going from 5 to 6 bytes.
Meanwhile, ARM/RISC-V can use 32 registers and use 3-register assignments with just 2/4 bytes.
https://cdrdv2.intel.com/v1/dl/getContent/784266
It looks like it uses the 4-byte EVEX prefix. It would also need 1-2 operand bytes and another register byte.
That's 6-7 bytes for basic 3-register instructions. If you need to do something with an immediate/displacement value on the top 16 registers, that seems like it would be potentially 10-12 bytes long including 4 bytes for the value and 1 byte for the scaled index for displacement.
I'll admit I don't have time to read the article at the moment and I'm wondering if my fast look is wrong. If not, I don't see how the extra registers are going to be worth the massive instruction length.