PAK Diffie-Hellman vs. sharing high-entropy key In order to setup an authenticated shared secret key between two clients, I am faced with the choice between two possibilities:


Let users set a (low-entropy) shared password and then perform some password-authenticated key exchange that is resilient to low-entropy secrets (as described here, for example).
Generate a high-entropy shared key and use it directly as a shared key.


Are there any advantages to “1.”, especially when users must communicate the password/key through a separate channel in both cases? 

Nota Bene: The resulting shared key is used only once per client (Alice $\rightarrow$ Bob and Bob $\rightarrow$ Alice) and subsequently destroyed.
Are there any advantages to “1.”, especially when users must communicate the password/key through a separate channel in both cases?

As the comments (1, 2) already indicated: the first option “1.” will be easier to communicate.
When you talk about a “high-entropy key”, I assume you are generating that high-entropy with a cryptographically secure random number generator. To make such a random piece of data easy to communicate among humans, you would need to convert it to something like Base64… which means “2.” will have a longer message which needs to be communicated between humans. The longer the message, the more room you’re providing for potential human error during that communication.
To keep human communication easy, you could stick to option “1.” and let users set a (low-entropy) shared password. You can always opt-in to a kdf if you want to make it computationally more difficult to crack attack the user-chosen passwords.
Please note that I’m assuming you generate and communicate that shared key without allowing impersonation. If you don’t authenticate communication, no entropy in this universe is going to help.
TL;DR
I would advise to prefer PAK Diffie-Hellman (as described in RFC5683) because it additionally offers authentication, while sharing a high-entropy key without authentication merely provides more entropy… but not a single bit of security which could prevent impersonation (man-in-the-middle) et al.