Your understanding is broadly correct, but in security and especially in cryptography, “broadly correct” often doesn't cut it.
There is a standard for encryption using elliptic curve cryptography to encrypt data, called ECIES (Elliptic Curve Integrated Encryption Scheme). (IES can be used with other key agreement methods, but only elliptic curves give it practical advantages over RSA — faster decryption, smaller keys.) The procedure is as follows.
- Alice obtains Bob's public key on the selected elliptic curve.
- Alice generates a random key pair on the selected curve.
- Alice calculates the shared secret for Bob's key .
- Alice passes the shared secret as input to a key derivation function (KDF).
- Alice uses the output of the KDF as a key for symmetric authenticated encryption.
- Alice sends the resulting authenticated ciphertext and her public key generated at step 2 to Bob.
The KDF step is important because a shared secret generated with ECDH is not uniformly pseudorandom. An attacker may be able to get partial information about it by simple mathematical observations (for example, the shared secret is a number between 1 and N where N is not a power of 2, so the highest bit is biased towards 0), by conducting key agreements with Alice using a series of intelligently-crafted keys, or by observing side channels from the ECDH computation. Partial information about the key can allow a related-key attack on the symmetric cipher. Passing the shared secret to a KDF “scrambles” any mathematical relations in the output.
In RSA-based hybrid encryption, the same symmetric key is never generated twice because it's generated at random. In ECIES, the same symmetric key is never generated twice because it's derived from an elliptic curve key that is generated at random.
The calculation of the shared secret is exactly the ECDH calculation. It's sometimes known as “ephemeral (elliptic curve) Diffie-Hellman” because the private key is single-use. Ephemeral and non-ephemeral Diffie-Hellman are the same algorithm, what “ephemeral” means is that the key is used only once.
From a cryptographic point of view, the output of the KDF can be used to encrypt more than one message. (But always with the same algorithm. Using the same key for two different algorithms, e.g. for both AES-GCM and AES-CCM, or for both AES-GCM and Camellia-GCM, could be anything from a subtle weakness that reduces the security by a bit and a half, to a catastrophic weakness that makes it easy to recover the encrypted message.) After all, if you have a symmetric key, it doesn't matter how you got it. Whether you'd want to do that is an operational matter: how much of a risk is there that Alice or Bob will accidentally leak the symmetric key? How much of a risk is there that Alice will generate the IV incorrectly for the symmetric encryption step? If you aren't worried about these risks then you can treat the symmetric key generated from the shared secret like you'd treat any other shared key, minus the problems of distributing this shared key.
Alice can perform the shared secret generation with the same inputs more than once if she wants: she'll get the same output each time, so that won't provide extra information to an attacker. The danger if Alice reuses the ECDH key is that this creates more risk that the key will leak, either from storage or through side channels.
It's even safe for Alice to use the same key pair to communicate with more than one party.
Just because everything is safe in principle doesn't mean it's a good idea. The more you leave a key lying around, the more risk there is that a partial compromise will reveal this key.
A common reason to reuse the ECDH key is to put it in a high-security piece of hardware that will perform operations with the key but not reveal the key itself: smartcard, secure element, HSM. However, this is useful for Bob, not for Alice. Bob needs to somehow send his public key to Alice in a way that Alice will trust, and after that he needs to hold on to the key. On the other hand, there is no strong advantage for Alice to reuse her ECDH encryption key, since she'll send the public key as part of the message.
A valid reason to reuse the key is if you have stringent constraints on message length. It lets you save about 65 bytes (size of an uncompressed point representation on a 256-bit curve) can be useful.
Performance, on the other hand, is not a strong reason. Generating an EC key is extremely fast: it's just a uniform bit string of the right length (this is unlike RSA where key generation is very expensive). You need to add the time it takes to calculate of the public key, and that's basically the same calculation as the ECDH calculation. So setting up ECIES-like encryption with a stored key instead of generating the key only divides the time of the asymmetric-cryptography part of the computation by two.
Finally, note that even if you reuse the EC key, you can still derive as many symmetric keys as you want. The KDF step takes an optional extra input which can be public. This extra input is variously called a salt, a label, an info string or various other names. You only ever get the same KDF output if both the secret input and the salt are the same.