> If the client doesn't trust the server, the crypto protocol is a little irrelevant.

What? No. The protocol is the only thing that is relevant. Peers don't generally trust each other a priori at all. They trust the protocol. If they can authenticate each other within the bounds of the protocol then they trust each other. If one party no has reason to distrust a certain protocol, then it should not be used as a basis for establishing trust. If the two peers can't agree on a protocol: stalemate. If I compromise your server and only serve weak protocols a responsible client won't authenticate me whereas a vulnerable client would take my word that my protocol is secure.

If don't trust a server, then any strong protocol that results in a secure shared secret or session key is trivially sidestepped by the server intentionally leaking these secrets or keys.

Two interpretations of the same phrase:

1. Do you trust that 123.123.123.123 is the real https://example.com ?

2. Do you trust the real https://example.com to not leak?

The protocol is for 1. You’re right that nothing can help with 2.

I trust the server only after I verify its PK. SSH performs mutual authentication.

We’re talking about rotation though, something that can be triggered when both sides are authed.