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.
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.