That statement is somewhat inaccurate (I see no a-priori reason why varying-length instruction sets should be harder to pipeline, if properly designed), but probably refers to the fact that in MIPS, instructions are fixed-length, 4 bytes; Whereas in x86 instructions can vary in length from 1 to 15 bytes at most (17 is incorrect), making the decoding step within a pipeline hairier.
Since the instruction length varies, it is much harder to discover instruction boundaries in x86, because the current instruction must be decoded before the CPU knows where the next one starts, and the next one, and the next one etc. In MIPS on the other hand, a +4 increment is, guarantee, all you need to step to the next instruction (except if there's a branch in your pipeline), and what's more these instructions are also aligned on 4-byte boundaries.
The other problem this statement may refer to is that in x86, special prefixes (such as REX, VEX and LOCK) and suffixes (SIB) can be added to instructions to modify their behaviour, such as granting access to more (r8-r15) and wider (eax -> rax, XMM -> YMM) registers, more operands (VEX 3- and 4-operand non-destructive-store instructions, in which the destination register isn't necessarily one of the source reigsters), locking the system bus to make an operation atomic, or specifying a scale, index and base displacement as a memory operand.
These prefixes and suffixes make life hard because the more of these there are in the instruction set and the more substantially they modify the meaning of an instruction, the longer it takes for the decoding step to determine what exactly is to be executed, where to pull all the operands from, and where does the next instruction start.
Longer instructions do not necessarily encode more "operations". Your hunch about some x86 instructions containing massive constants but still doing only one "operation" is right on the dot!