8085; Why RET doesn't require a 6 T-states Fetch cycle?
It would be insightful to analyse CALL instruction once more before talking about RET instruction. 

CALL INSTRUCTION IN 8085

As you stated, it consists of: Opcode Fetch, Memory Read, Memory Read, Memory Write, Memory Write

8085 follows decrement and push methodology while pushing to stack.

Opcode Fetch in 8085 is typically 4 T states. However for CALL instruction, it takes 2 additional T states. It is because - After the fetch and decode, the stack pointer has to be decremented ahead of the first Memory Write cycle that will store the current PC's MSB to the stack. 

During the first Memory Write, the value is pushed and the stack pointer is decremented again by the processor. This is done in parallel, so that next Memory Write cycle can begin immediately without losing additional T states. In the second Memory Write, PC's LSB is pushed to the stack, but the stack pointer need not be decremented as there are no further writes coming.

Memory Read cycle is where the branching address is stored in WZ internal registers.

Each Memory Write is 3 T states and each Memory Read is 3 T states as well. 

So total T states = 4 + 2 + 3 + 3 + 3 + 3 = 18 

RET INSTRUCTION IN 8085

It consists of: Opcode Fetch, Memory Read, Memory Read

Again, Opcode Fetch is 4 T states. However 8085 follows pop and increment methodology while popping from stack. The stack pointer is already pointing to the LSB of the return address, so there is no need to increment the pointer beforehand. 

During the first Memory Read, the pointed value is read, and the stack pointer is incremented by the processor as well in parallel. During the next Memory Read, the MSB of the return address is read and the stack pointer is again incremented in parallel.

So total T states = 4 + 3 + 3  = 10

So in RET, there are no additional T states needed after Opcode Fetch unlike in CALL.