It seems most CPU designs favored CISCish instruction sets that accumulated a lot of propagation delay on the long combinatorial logic paths needed for that. Which usually limited the overall CPU clock to a small fraction of the "raw" speed of the ICs used.
First of all, CISC doesn't require longer combinatorial delay. If at all, it usually results in more clock cycles per instruction.
Further when it comes to more complex combinatorial logic it's rather the other way arround. With a monotone clock, it's period must be as long or longer than the slowest element used. So if there are for example three stages with 5 ns, but one with 20ns, the system clock can't go past 50 MHz. An instruction going thru these 4 stages will take 80ns. Now if these 4 elements are part of a single 'complex' stage defined by their combinatorial speed, it will only take 35ns for an instruction to pass - more than double the speed of single stages.
Creating many small stages is only a benefit if they are part of a pipeline - here more than one instruction can be in processing at the same time. While a single instruction will still take the same (often more) execution time, they work more thna one instruction can be in execution, thus increasign effective thruput.
The CISC-ness preference is also understandable for most applications, since there likely was much more need for the assembly language specification being something that a human programmer could make sense of.
Not realy. Instruction sets where always made with a focus on a possible machine structure and the task to be solved, pleasing programmers always came second.
As shown beore, the power of CISC comes from higher speed. This is even more true when considering that Memory of early machines - until the mid 1970s - was magnetic core. Core started out with cycle times of 6 to 9 microseconds. Even a true high speed machine like the CDC 6600 only managed a cycle time of arround 1 us. It didn't improve much from there on. the last generations arround 1975 where still 0.6 us or above. 600 ns is something where quite a lot of computation can be done.
Were there exceptions (especially earlier or more radical), apart from the first Cray designs, where non-orthogonal instruction sets that kept the propagation delays short - and/or pipelining - were used?
It wouldn't have made any sense. The bottleneck wasn't command execution but memory read. Thus shorter but more complex intructions where the way to increase performance.
The CDC 6600 is in fact a great example how to work arround the memory problem. While the CPU clock was 10 MHz, the memory cycle was 1 us (1 Mhz). Similar the PPUs. There where 10 of them, each operating with a 1 MHz clock, but interleaved. To feed all of this memory was also build up as 32 interleaved blocks or 4096 words with 12 Bit each. Each PPUs could get each one word per turn as long a it was mostly consecutive. Well, it wasn't always, and thruput was quit dependent on the way instruction stream (and data) was aranged
So while the CDC was already somewhat RISCy, it was way more limited by memory speed than gate speed or clock rate. The whole idea behind this rather extreme design was to squeeze as much action arround the slow memory. Other, much simpler design where just condemed to wait for the momory most of the time.
And it didn't feature any pipeline at all. Especially not one having different instructions in different stages of competion - like you question may assume.
Now while the next step, the 7600 did crank up clock speed to 35 MHz, its memory was in fact slower with about 1.4us. This got leveled by a more sopisticated structure, now including a pipeline - quite unlike a 'classic' instruction pipeline, more like a reordering buffer to find instructions that can be issued to some function unit in parallel. But even with this much more sophisticated structure, memory was still the bottleneck, not any clock speed or instruction set.