Is depth and number of stages the same measure for a CPU pipeline?
I would argue that "depth" is a measure of instruction overlap in the sense that it indicates the amount of time (number of clock cycles) that must elapse before the result of one instruction can be used by a subsequent instruction.

However, there might be additional hardware stages (instruction prefetch and decode, memory write, etc.) that do not contribute to this latency, so the "number of stages" could very well be larger than the "depth".

The "optimal depth" concept arises from the fact that doing a small amount of work in each clock cycle (having a large number of stages) allows a higher clock frequency, but also increases the depth (latency). Eventually, this becomes a liability, because it can get to the point where the compiler has no useful instructions that it can schedule to fill the gaps imposed by the latency.

This was not much of an issue for early supercomputers, because they were focused on processing large arrays or vectors of data that had no data dependencies among the individual operations, and so they could afford to have deep pipelines that ran at high frequencies. However, "random" calculations on scalar data generally have more data dependencies and much shorter latency requirements, which leads to the need to keep the pipeline depth relatively small. If not dealt with, this "scalar bottleneck" can severely limit the overall performance of an application, which is what Amdahl's Law is all about.