In many cases, undocumented opcodes were not deliberately created, but are merely the result of designers including the minimal circuitry necessary to create a specified set of opcodes. On the 6502, for example, consider how one might go about creating the instructions LDA, LDY, and LDX. Rather than handling the three instructions separately, it would make sense to have six bits of the opcode mean "load something with address mode __", and then use the remaining bits to control the enables of the registers.
While it would be possible to have each register-enable respond to one particular pattern of those last two bits, one can save a few transistors by saying that one register responds when bit 0 is high, one responds when bit 1 is high, and one responds when neither is high. As it happens, that's exactly what the designers of the 6502 did. The bit pattern 101mmmrr is the bit pattern for "load something to the register specified by using memory mode m" opcode. If rr is 00, it loads the Y register; if the lower bit of rr is 1 it loads A, and if higher bit of rr is 1 it loads X. Now for the undocumented part: If both bits of rr are 1, it loads both A and X.
Unfortunately, because the designers of the chip never realized that loading two registers with one instruction might be useful, the decoding circuitry for some other instructions will also respond to bit pattern 10101011 which would be "load immediate, enabling both A and X". As a consequence, while the most useful memory-addressing mode for loading both A and X together would be immediate, there is no usable "load A and X immediate" instruction.
I would expect that the biggest reason many such opcodes were never documented is that the chip designers probably never gave any particular thought to the possibility that bit patterns to which they had never attached any particular meaning might actually serve some useful purpose. What makes this particularly bizarre in the case of the 6502 is that there are a number of cases where instructions don't support an addressing mode, but an undocumented variation does. Two of the most notable examples:
LDX does not support the indirect, Y addressing mode, but LAX does. As a consequence, it's sometimes useful to use LAX even in cases where the value in the accumulator afterward is irrelevant, since it's two cycles faster than doing an LDA followed by a TAX.
DEC only supports absolute, abs+x, zero page, and zp+x addressing modes, but the bitwise OR of the DEC and CMP opcodes will act as a DEC that supports any addressing mode that CMP supports other than immediate, and which will set flags on the result in the same way that CMP would set flags based upon its operand. Thus, code which needs to perform a DEC using some other addressing mode can use "DCP", whether or not it needs the flags (though in many cases setting Z based upon whether the value was decremented to match the accumulator--rather than zero--can be a nice bonus).
DCP brings up an interesting point: the 6502 documentation specifies that the maximum time required to execute any opcode is seven cycles, and some system designs might rely upon the worst-case interrupt response time that would imply. The indirect-X and indirect-Y variations of DCP take eight cycles. The 6502 executes them without difficulty, but some systems might have trouble if the interrupt line is sampled just before the interrupt line becomes active, and the next instruction is an eight-cycle DCP. While it might be considered bizarre to design a system that has zero margin on interrupt response time, there were many cases where an interrupt source would be synchronous with the CPU clock, and where hardware to allow precisely as much time as the 6502 required for an interrupt response would be cheaper than hardware which could allow one more cycle.
