Signal Protocol - Counter over TCP? Signal Protocol uses a counter (discussed in DoubleRatchet documentation) to define how many times KDF has derived a new key (aka a KDF step) which is then sent along with every message for the end client to know how many derivations (steps) he has to do to obtain a decryption key matching the message key which encrypted the message.

Note: it is also used for creating a message mac which is later compared for verification, but since both clients are keeping track of the current counter it should match as long as the order is intact.

This makes sense for protocols that don't have order, but if I am using TCP which keeps order does sending the counter and skipping over messages has any use?
You are confusing TCP packets and Signal messages.

First, TCP ensures the order of packets inside a session. TCP does not ensure the order among sessions. This means that TCP cannot be used to ensure that the Signal messages are received in the order they were sent.

Also, TCP was not build to resit active tempering by a MITM agent, unlike Signal. It would be extremely unwise for Signal to assume that the properties of TCP are reliable. 

Moreover, the end client might not keep track of the previous messages: they could be deleted or the client could have been reinstalled on another device (while keeping the secret keys).