The only problem with a pipeline is the startup time after an unexpected jump.

You don't have to worry about any reset conditions. Normal speculative execution just means that you can throw away results at the last step of the pipeline. Form the programs view, an instruction hasn't happened unless the last step in the pipeline gets accepted.

With a short pipeline, you need to be able to see the startup time either. After a reset, it may take a couple of cycles extra until the first results gets produced. In the same way, an interrupt will require these cycles until activated, but these cycles would normally be so much shorter (the pipeline allows a higher clock frequency, since you limit the sequential state changes required for a step in the pipeline) that the total number of nanoseconds for the interrupt response will not be affected. The ALU etc of the 8051 are so tiny that it is very easy for the pipeline to compute both sides of a conditional branch, and throw away the wrong alternative.

In the end, a pipeline need not affect any predictability. You could still count your cycles for the individual instructions. It isn't until you start with instruction reordering or concurrent (accepted, instead of speculative) instructions that you will lose the ability to compute exact timing.

Viewing many bytes of the instruction stream without a pipeline gives the processor information it can't make any use of. The ALU, address busses etc will not be any faster just because you have knowledge about following instructions.

Think about discrete logic. How much can you manage to do in your discrete logic with just one clock transition? Each gate will have a delay, and your information may in some situations have to ripple through the logic gates and flip-flops. Using a two-phase clock, you would still have quite interesting times to get data from the code space, decode, retrieve input data, compute and store back the result within one low-to-high and one high-to-low clock transition.