Is a key ratchet effective against replay attacks? In the answer to this question, a message counter is used to protect against replay attacks. Could a key ratchet be used instead? The basic idea is that with every message sent, the symmetric encryption key is replaced with a hash of itself. The receiver can then reject any messages that use previous keys.

The benefit of this approach is that a counter doesn't need to be sent on the wire, so bandwidth is saved. I'm designing a system where bandwidth is constrained, but computation not so much so performing a hash with every message is not a problem (and having the receiver possibly try multiple keys in the case of message loss is not a problem either).

Is using a key ratchet any less effective at protecting against replay attacks than a message counter? Are there any other reasons not to use such an approach?
Yes, a ratchet is an effective way of preventing replay attacks.
For example, the Signal Protocol does this (for reasons other than replay protection), and it is stated in a blog post that the replay protection "comes for free".

Since your transport protocol can lose messages, I would assume it also does not guarantee the ordering, so you will have to store some skipped keys. In fact, the Signal Protocol I just mentioned still sends a counter for this bookkeeping reason as you can see in the actual specification. You will have to decide if trying the skipped keys in order is computationally feasible. This issue is related to the first attack scenario described in the first answer of the question you linked: an attacker who can hold back messages and replay them at a later time would still be successful.

If you do not authenticate your messages, this scheme also enables DoS attacks - an attacker simply has to send enough messages to fill up the buffer of stored keys, and you will not be able to decrypt legitimate messages. While this prevents an attacker from using garbage data as keys, he can still use old messages with legitimate keys for this purpose. The result is that you have to keep track of old keys as well, add a counter, or invalidate old authentication tags by e.g. also evolving the key material used for signing.