What are the advantages of using "static-ephemeral ECDH" over "ephemeral-ephemeral ECDH"?
Well, the advantages of static-ephemeral ECDH (and, they apply to DH as well):
You get one-way authentication for free. That is, if Bob has Alice's public ECDH key, and uses it to talk to someone, Bob knows that that someone is Alice, without doing any further checks. Now, Alice has no idea who she's talking to; on the other hand, for some scenarios, Alice really doesn't care.
You don't need a reply from Alice to get her ECDH public value; you already know it. This may allow you to use one fewer protocol round (depending on what else needs to be done on the protocol). In fact, if all Bob wants to do is share a symmetric key so he can send Alice a message, he doesn't need any replies from Alice at all; he can generate his public value, and the message encrypted and authenticated with a key derived from the shared secret. Doing this is actually known as the Integrated Encryption Scheme; if this is what you're doing, you might want to look at the standards (as people have thought through the details)
Of course, there are some downsides:
It means that Bob has to get Alice's public key in a way that is authenticated. If that means that Bob has Alice's key in a database, well, there are some practical questions with that (such as when Alice creates a fresh key, how does Bob hear about it).
If Alice does care who she is talking to, that means Bob needs to authenticate himself. If you need to do this, you lose some (but not all) of the advantages you get from preconfigured keys in the first place.
You lose the Perfect Forward Secrecy properties that are normally associated with DH; you may or may not care depending on your security assumptions. That is, if someone gets their hands on Alice's private key, then they can not only impersonate Alice, they can go back and decrypt previous sessions.