Result of increasing number of stages in pipeline processor
Ideally, it can be simplified a lot. Suppose there are these classic five steps needed to complete an instruction:


IF -- instruction fetch from instruction memory (also increment PC)
DECODE -- instruction decode
EXEC -- instruction execution (ALU operation, for example)
MEM -- memory read or write
WRITE BACK -- register write-back from ALU


(Sometimes, a separate 6th item is required to increment the PC.)

Not every instruction requires all of these, of course. But that's the basic layout.

Suppose this is NOT pipelined. Then the fastest clock cycle you can use is the longest propagation delay of the above (usually external data memory fetching or writing or instruction reading.) So you will need at least 5 cycle times, with each cycle time being the worst case of any one of the above. Let's call the worst case delay \$t_\text{worst}\$. So this means \$5\times t_\text{worst}\$ is your total execution time for an instruction and you'll require 5 clock cycles per instruction.

Now, suppose you can pipeline things so that all five of the above stages can execute in parallel. You still have to make the clock cycle be the worst case value, \$t_\text{worst}\$. But now the instructions can overlap. When one instruction is in its \$IF\$ phase, the prior instruction is now in its \$DECODE\$ phase. So the effect now is that each instruction overlaps its various steps with other instructions. The result is that the processor appears to execute 5 times faster. The price of achieving this is to make sure that up to 5 steps (if all different) can be performed in parallel. And that requires some extra logic.

Also, one can either deal with hazards or not deal with them (leaving the problem to the compiler and assembler, for example.) Dealing with hazards can be tricky and almost always lengthens the worst case magnitude of \$t_\text{worst}\$, too. Forcing the compiler/assembler to deal with hazards instead of added logic and stall cycles permits a smaller value for \$t_\text{worst}\$ and therefore a faster clock rate. Dealing with these in hardware increases \$t_\text{worst}\$ and makes for a worse clock rate. These are balancings a designer deals with based upon statistics about expected program code.

Pipelining does help a lot. And choices about how much is handled in hardware vs software also matters (because it changes \$t_\text{worst}\$.) But a simplistic view would say that for a given \$t_\text{worst}\$, pipelining helps by a factor of the number of parallel stages you can achieve (ignoring hazards.)