Meta: this isn't really a programming or development question or problem. It probably belongs on crypto.SX; you might ask for migration.
To be exact, ECIES is a hybrid public-key encryption scheme, but so are most others. For example RSA is commonly used, just as you said, to encrypt a working (per-message) symmetric key, not to directly encrypt data.
Paraphrasing the wikipedia description:
- (Usually in advance) Bob generates a (static) keypair and publishes the publickey authentically (for example using a certificate)
2-5. Alice generates an ephemeral keypair, derives the shared DEK, and encrypts the data, and sends it with her ephemeral publickey
(edit) and destroys the ephemeral privatekey
- Bob uses his privatekey to derive the DEK and decrypts the data
ADDED, and expanded below, per comments: Yes the DEK is the same at both ends (notice I used 'the' meaning one and not several) and that's why this scheme works; and the part of ECIES that uses DEK for data encryption and decryption is symmetric, but all the other operations (which securely create the ephemeral shared DEK) are not.
It is vital no one besides Alice (or Bob) learns her ephemeral privatekey; if they do they can decrypt. But she doesn't need to explicitly keep it secret because she destroys it immediately after using it to send a message; that's what ephemeral means.
Let's see:
the recipient's publickey is public and anyone can encrypt
the recipient has the (static) privatekey and can decrypt
nobody else has Bob's (static) privatekey or Alice's ephemeral privatekey, and nobody else can decrypt
the recipient needs only one keypair; if there are multiple senders they can all use the same publickey but can't decrypt each other's traffic, and don't need to get the publickey secretly; for a thousand or a million senders this costs the same as or very little more than one sender
Consider the properties of a standard/traditional symmetric scheme instead:
the two parties must have a key (only one, not a pair) shared in advance; both must keep it secret and not share with anybody else
this typically requires the parties meet in advance, or use a physically secure means such as a courier to carry the key from one to the other or perhaps from a central authority to both
each key can only be used by one pair of parties; for multiple senders, Bob must have and manage that many different keys, and each sender (Alice, Abby, Anne, etc) must have a different key. Each sender must separately meet Bob, or they must each have a separate courier (or two), before they communicate with him. For a thousand or a million senders this becomes immensely costly
ECIES has none of these properties of a conventional or symmetric system, and all of the properties of a publickey or asymmetric system above, although it does also use some symmetric operations along with its asymmetric operations.
And that's why it sounds like (hybrid) public-key encryption to me!