There are many reasons one would choose to implement a CISC. The most prominent reason is for binary compatibility with an existing CISC instruction set. While software binary translation technology has improved, hardware-based compatibility has some technical advantages (as well as the disadvantage of less translation caching) and the less technical advantage of seeming more reliable.
Code density is perhaps the second most significant reason for choosing CISC. The Renesas RX was designed as a CISC specifically for code density as it targets microcontrollers where code memory size is a significant cost factor. Variable length instructions, complex instructions (mainly more addressing modes), implicit operands, and lower register count all benefit code density.
An historical (and in my opinion misguided) reason for choosing CISC was to close the semantic gap between programmers using a higher level language and the processor. Since complex instructions can generally be replaced by a sequence of simpler instructions, the complexity of a higher level language compiler for a RISC need not be much more complex than for a language-matching CISC. RISC avoids "semantic clash" (where a processor instruction does more or less work than a corresponding language statement) and facilitates strength reduction and scheduling optimizations. (See "What are the tradeoffs in compiler development effort related to CISC vs. RISC?" for more details.)
There can be a significant fixed cost associated with executing an instruction. This encourages the use of relatively complex instructions to spread this overhead over more actual work; reducing the dynamic instruction count can improve performance. When the cost of logic and RAM was much greater than the cost of ROM, the incentive for complex instructions was significant since an instruction was decoded by looking up microcode.
A reason to use CISC that is perhaps contradicted by historical evidence is that microcode can be optimized for each microarchitecture whereas standard libraries may be slow to exploit features of a new implementation. The optimization level of software implementations of memcopy versus that of the microcode for REP MOVSB implies that libraries can get more attention than microcode. Part of this may come from the processor vendor targeting a broader user base so justification of effort may be more difficult compared to open source or internal software where localized interests of developers or users can bias implementation effort.
Being able to ship an optimized standard library with the processor does have significant attractions. The storage and execution of a platform standard library can be significantly optimized by software-hardware codesign. The distinction between a complex instruction and a Platform Abstraction Layer call can be subtle (or non-existent). A RISC design could use the same implementation techniques for handling PAL calls as a CISC does for complex instructions, including using operations not provided in the general instruction set with specialized hardware, using clever caching and decoding, and specifying register operands (though a CISC would often use dedicated registers similar to a per-function ABI). The mental model associated with CISC can encourage such optimizations. In addition, users may be less offended by the forced inclusion of a "hardware" standard library (CISC) than by forced inclusion of a specific PAL library.
Decoding relatively complex instructions can have less overhead (and possibly more reliably be correct in discerning intent) than the comparable RISC technique of idiom recognition where a sequence of instructions is recognized as a semantic unit. This overhead difference would be most noticeable in a smaller implementation, but the overhead to use this information reduces the significance of the decode savings.
Additional contextual information can facilitate hardware optimization. For example, when incrementing a value in memory, hardware could recognize that the memory address is used twice (for the load and the store) providing an opportunity for cache way memoization and translation caching. Complex instructions can provide such information explicitly. In a complex instruction, intermediate values have an explicit lifetime (that of the instruction); with a traditional RISC register values must be explicitly overwritten to indicate the end of liveness. (Note: A RISC could specify a register which is always zeroed after each use, providing a means to specify a single-use temporary value. Such instructions would be moderately more complex.)
If implementation details are not hidden behind an abstraction layer, it becomes more difficult to use different microarchitectures to optimize for different tradeoffs. Exposing microarchitectural details as architectural guarantees locks the microarchitecture into the compatibilty guarantee. While PAL software could be optimized the same as complex instructions, such requires hardware-software codesign. Organizational separation and diversity make codesign more difficult.
Complex instructions can provide guarded access to privileged state. For example, complex instructions are often atomic with respect to interrupts. While a RISC instruction set could provide a user-level mechanism to temporarily suspend interrupts, possibly even something like linked-load so that software explicitly retries the operation if interrupted, providing such is not typical for RISCs.
Similarly, a complex instruction could provide controlled access and/or use of privileged information. Because the executed operation has controlled semantics, actual privilege violation can be avoided. RISC-oriented alternatives include PAL code (which typically has significant overhead) and masked access to configuration registers (or shadow copies of registers) that have some privileged state. Providing a general solution (RISC) is more difficult than providing a solution to one or a few special cases (CISC), but is more powerful and less vulnerable to accumulation of special cases. If one believes that the important special cases are few, CISC can be more attractive.
Complex instructions can also hide state from software. One prominent advantage of such would be for context saving and restoring. With instructions that save and restore state, the architecture only needs to communicate the context size to the OS not the specific mechanisms for transferring state to memory. This allows applications running on a legacy OS to use ISA extensions which add state. (Again, PAL software could provide the same functionality.)
Much of the complexity of x86 comes from compatibility across many extensions. With complex and less orthogonal instructions (useful for code density), removing some work that turned out not to be commonly needed, avoiding unnecessary dependency chains (e.g., only one carry bit, only one dynamic shift amount register), adding some work that turned out to be commonly used and that can be optimized within the complex instruction — any of these would require adding a new instruction and making the ISA less aesthetically pleasing.
In many cases a RISC would not encounter such issues because instructions are highly orthogonal and primitive. In some cases a RISC might need to add new primitives but such would typically be applicable to more than one use.
In addition, once the infrastructure is in place to support complex instructions, the barriers are reduced for additional complex instructions. That is, much of the cost of complex instructions in non-recurring. Strongly RISC ISAs suffer a complementary hinderance to introducing CISCy features.
The frequency of extension of x86 may also be partially attributed to its popularity for general-purpose computing and the merchant processor model (these also increase the importance of binary compatibility). RISC ISAs have often been tied to sysem vendors which encourages a narrower focus on applications and the lack of competition for implementations of a specific RISC ISA somewhat discourages the use of instruction set extensions for marketing. Popularity also makes the cost of developing new extensions less significant (non-recurring expenses are less important at higher volume).
The x86 compatibility philosophy probably also biases toward extending existing mechanisms rather than providing a more clean break which means that new features are more influenced by existing features. Higher frequency of extension also encourages more incremental changes, which encourages reusing mechanisms, tending to reduce orthogonality.
Comparing an academic presentation of classic MIPS (which is a subset of modern versions of MIPS and excludes various optional ISA extensions) to modern x86 (which traces binary compatibility back to the 16-bit 8086 and assembly-level quasi-compatibility even further back) with all its historical baggage does not present the best case for CISC nor a realistic case for RISC.