Actually, instructions don't all take the same time in RISC. They are forced to all take a fixed number of cycles, but the latencies will vary, and even within the same instruction. For instance, adding 1 to 0x01111111 is harder than adding 1 to any even number.
And you can do RISC or CISC regardless of the strategy used to obtain such an architecture. It isn't the number of instructions needed to produce a result that is the concern here, but more the variability of the lowest-level instructions.
Consider the clock rate, that is just the time it takes for the worst-case instruction (RISC) or instruction part (CISC) to consistently run reliably. It is the lowest common denominator and is applied to all instructions, even those with significantly lower latency. However, if you can run each instruction the precise amount it needs at a given time, you could improve performance.
So the above considerations affect your build philosophy. For a clocked system, you'd be racking your mind trying to figure out how to eliminate certain bottlenecks that are holding back your clock rate. For a clockless implementation, you'd be more concerned with improving the performance of nominal/average values and operations.
If you are designing a 6502-similar CPU using the synchronous approach, you'd be trying to figure out how to do BCD math faster to not slow the critical path for the rest. So maybe you'd use a carry-skip adder arrangement or break down your BCD instructions internally to require 2 or more cycles. You would figure that it isn't fair to hold back the other instructions because BCD is slower than binary math, and that making the BCD instructions require more cycles to complete by breaking them into smaller micro-ops would be worth it for a faster clock rate overall.
Designing the same type of CPU above, you wouldn't be as concerned with edge cases that take longer as they will be allowed to take what time they need when necessary. While you could do a carry-skip or CLA adder arrangement, you won't feel as compelled since the edge cases won't cut into the critical path in every instance.
Interestingly, this approach could even help slower operations. Consider an instruction that takes 1.6 times the usually-allowed latency. On a clocked system, you'd need to break that up into 2 instructions or micro-ops. On a clockless system, you can give it the exact extra time that it needs.
Back to the RISC part of the question.
It is easier to think of RISC in terms of fixed cycles, but it is more about the size of the building blocks you use. It is more about using instructions that just do one task (though that can be a group of things that happen coincidentally or in parallel) as opposed to using larger instructions that require a number of sub-tasks performed in series. This distinction can be blurry at times. For instance, the Gigatron TTL computer is a RISC machine on the native Harvard side, but there are a few instructions that do up to 3 things at the same time (OR/AND during a memory read and route that to the port while incrementing the index register). Now, instructions such as that are used to make the vCPU interpreter that allows user code to run, and that is like microcode in that it builds more complex instructions.
So once you take the clock off the table, then you'd still have a RISC machine. It would be harder to quantify as such, but that won't change. What will change are the latencies per instruction (and even within the same instruction ran at different times such as math operations). Clocks are just arbitrary time units designed to take the worst cases into account. But you could otherwise use a RISC model. The clock thing is about a different type of granularity than what is commonly thought of in RISC v. CISC.