First of all why not KK? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer.

It isn't really possible to tell who is connecting to you based solely on the IP information you receive. The public IP information received over the gossip protocol only lists the listening endpoints which you can connect to, but this does not imply that those endpoints will be the ones connecting to you. In fact, they can't be, because the listening port requires a dedicated socket, so any outgoing connections from that IP would be on a different port. The port for outgoing connections is usually assigned automatically, although you can bind it to a specific local port explicitly, this is not common. You can't bind to the same port as the listening socket anyway, and if you're behind a NAT you have no control over the port the recipient might see at their end.

The IP address alone is not sufficient because you could have many nodes behind the same IP on a network, or due to NAT. It would be guesswork which node you think is connecting to you to try and pick the right public key.

Since the initiator's key can't be known for sure, the other options from the Noise protocol are N, I or X. We can rule out N because it does not provide the security guarantees you listed above, and I leaks information in plaintext which could be intercepted. X is therefore the most reasonable option.

For the responder's public key, we can again rule out N, leaving either K or X. We already know the key though, from the gossip network (or DNS), so there is little point on transmitting it also. Additionally, the recipient has a little extra information hiding because their public key is never transmitted.

The Lit project from MIT uses the XX pattern. I believe this is because nodes don't have information about public keys in advance because they use hashes of the public keys to identify nodes instead. Once the public keys have been transmitted, their hashes can be compared to the previously known public key hashes.

Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively?

The reasons are as you've listed from the Noise protocol document. The public keys alone are sufficient to have both encryption and authentication without relying on any third party for the security guarantees. Other protocols such as SSL have inherent points of failure - such as the PKI, which has been abused for many real world attacks on security. (In addition to it being a rent-seeking industry.)

In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys.

The purpose of the key rotation is to prevent the decryption of older messages if the keys are compromised in the future. This could also be done with a new Noise exchange each time, but from a practical point of view it is more computationally expensive to do a handshake (multiple ECDH calls) than to produce new keys with the HKDF. There may be some other risks to it that I'm not aware of though.

I try an answer myself. It seems desireable to achieve forward secrecy for longterm security and protection of static key leakage and authentication to avoid spoofing. The only patterns which achieve both are the ones that use static keys and either knowing or transferring them.