This is not the case.
"op a,b,c" is totally equivalent with "mov a,b; op a,a,c". No more space in form of temporary registers at all. Destructive opcodes have never been an issue for vectorization.
It has some impact on the microarchitecture implementation, because you want to have to additional move for free as often as possible.
Technically, a destructive 2-operand format will use an extra temporary register in that case ...
2-operand format:
Suppose reg0 = a and reg1 = b reg2 = undefined (you start out with 2 registers here)
mov src0:reg0 dest:reg2 (you are now using 3 registers, you started with 2 but now you need a temporary register here to copy value from register #0 to register #2)
op src0:reg0 src1:reg1 dest:reg0 (3 registers used in total)
3-operand format:
Suppose reg0 = a and reg1 = b reg2 = undefined (you start out with 2 registers here)
op src0:reg0 src1:reg1 dest:reg2 (you end with 3 registers used but notice that's there's no intermediary step here)
That potentially means spilling can happen with destructive 2-operand instructions during copying step compared to the constructive 3-operand format so even if both of these cases start with 2 registers and ends with registers used in total. If you want to reuse data, a machine with a destructive 2-operand format will have to use 3 registers
earlier before performing the operation. This ultimately means that a destructive 2-operand format will comparatively place more limitations on data reuse in some programs and thus will complicate compiler design ...
Now that I've elaborated on further what I meant by "temporary register", I will tackle the subject of predication and masking ...
The problem with SVE here aren't the destructive instructions since they support masking. It's the constructive instructions which lacks support for masking. Masking is helpful for auto-vectorization since some loops may contain conditionals. Unfortunately with SVE, not every instruction supports predication or masking so some loops don't get auto-vectorized ...
ARM Ltd might have to go back to the drawing board again and create a new SIMD extension if compiler issues start to crop up because it'll discourage adoption among other vendors since it's added implementation complexity with nearly no benefit ...