The documented execution times count the cycles required to execute the instruction itself, including any memory accesses caused by the instruction, and ignoring everything else. The Intel manuals provide pseudo-code showing what each instruction does; you can consider that the cycle counts cover that, only.
Thus in CBW’s case, the iAPX88 manual shows:
if (AL) < 80H then (AH) ← 0 else (AH) ← FFH
In CALL’s case:
if Inter-Segment then
(SP) ← (SP) - 2
((SP) + 1 : (SP)) ← (CS)
(CS) ← SEG
(SP) ← (SP) - 2
((SP) + 1 : (SP)) ← (IP)
(IP) ← DEST
which covers the pushes. When moving to the 386, both instructions gain 32-bit variants (98h is CWDE in 32-bit mode) which can explain the added cycles: you need additional checks to choose between 16- and 32-bit behaviour. (The instruction mix changed quite a bit anyway so different cycle counts aren’t surprising on a 386 or 486.)
In particular, the execution times ignore three of the main “cycle eaters” (up to the 486):
- the prefetch queue, which takes time before an execution starts running and is variable based on circumstances outside the executed instruction’s control;
- DRAM refresh, which steals memory cycles independently of executing instructions;
- wait states, which delay instructions in variable ways again outside the execution’s control;
and eaters relevant on later CPUs, including:
- the effects of caches;
- alignment penalties (which can be calculated using the number of memory transfers, which is documented in some timing tables).
This explains why the cycles given for any specific opcode are constant (or deterministic formulas), at least before Pentiums: any variability is excluded. It also explains most of the differences between 8088 and 8086 instruction times: any two-byte access takes four cycles more on the 8088 than on the 8086. It explains the
CALL timings too: 23 cycles is for a near direct call on the 8088, where the relative displacement is in the prefetch buffer and doesn’t need to be retrieved; the time taken here is the push required for the 16-bit near return address, which explains the four-cycle difference compared to the 8086. A far direct call takes 36 cycles on the 8088 v. 28 cycles on the 8086, i.e. the difference in time taken to push two words to the stack.
The ultimate reference for all this, up to the 486 era, is Michael Abrash’s In the Lair of the Cycle-Eaters chapter in the Graphics Programming Black Book (which is adapted from Zen of Assembly Language). After that you should check out Agner Fog’s optimisation manuals (and starting with the Pentium, things get quite a bit more complicated, even more on the latest CPUs which have many other sources of variability). The timing table you link to is greatly simplified, there are much more detailed tables available in Intel’s documentation or in books such as The Processor and Coprocessor.