When the condition gets checked in the 6th T-state itself and is found to be not satisfying, why does it need the 2nd machine cycle?
CALL is a 3-byte instruction.
If the call is going to be taken, obviously all three bytes of the instruction need to be fetched so that the PC can be updated. Additional machine cycles are required to write the old PC to the stack.
If the call is not going to be taken, the PC still needs to end up pointing to the next instruction after the CALL. The easiest way to do that is to go ahead and fetch all three bytes, incrementing the PC once during each machine cycle.
I may have answered too hastily. I can't find any reference that shows the cycle-by-cycle execution of a taken/not-taken conditional call, but I did find that the execution time is either 9 or 18 clock cycles.
All of the references show that the first machine cycle of a call is 6 clock cycles, and if the call is taken, an additional 4 × 3-clock machine cycles (two to fetch the target address, two to write the PC to the stack) would indeed add up to 18 clocks total.
But if the call is not taken, there is only one additional 3-clock machine cycle, which suggests that the CPU does not fetch both bytes of the instruction, but rather updates the PC internally without executing the third memory cycle.
Curiously, the timing on the original 8080 (the chip on which the 8085 is based) is different — 11 clocks if not taken, 17 clocks if taken.1
This suggests that the initial cycle is only 5 clocks, rather than 6, and when the call is taken, there are four more cycles of 3 clocks each: 5 + 3 + 3 + 3 + 3 = 17 clocks. But in the not-taken case, the other two instruction bytes ARE fetched: 5 + 3 + 3 = 11 clocks.
This is probably what I was remembering when I wrote the initial part of this answer above.
1 From my copy of the 1977 Intel Data Catalog