From how I understand your question, I believe that you might have a few misconceptions about symmetric and asymmetric encryption. Let me try to clear things a little for you.
What is the real advantage of option 2?
Asymmetric encryption can be used in two ways:
- Provider encrypts with the public key of the consumer
This is the scenario you are speaking of. This approach is used to make sure that only one consumer can decrypt the payload. This is very commonly used in email encryption where only the recipient should be able to read the message.
In your environment, this could be used to provide a customer specific firmware that only one customer should be able to use.
- Provider encrypts with his own private key
In this scenario, any consumer could decrypt using the provider's public key. This approach could be used to make sure that only the provider could have encrypted the payload. However, to verify the origin of a payload, signing is commonly used. However, it uses the same principle: something only the provider can do with his private key, but can be verified by anyone using the provider's public key.
So, to answer your question about the real advantage of option 2, it does not seem to make sense in the scenario you describe, unless you want to provide customer specific firmware.
If somebody has the firmware package (or reads it while it is downloading), a lot of machinery and time, he should be able to decrypt the message anyway, because it was crypted with a symmetric key.
This sentence makes me think that you assume symmetric encryption is generally less secure than asymmetric encryption, and that, with enough resources, symmetric encryption can be broken but asymmetric encryption can't.
That is, in fact, not the case.
However, the one thing that makes asymmetric encryption preferable over symmetric encryption is key exchange problem. For symmetric encryption, it is necessary to somehow transfer the key to the consumer. This is problem part because the key might be leaked, and even worse, neither provider nor consumer might even notice it.
Interestingly enough, the common approach to this is in fact hybrid encryption. Asymmetric encryption is much more expensive and slower than symmetric encryption, but it has no key exchange problem. So we just use the best of both worlds:
First, we encrypt the payload using a symmetric key. Now to solve the key exchange problem, we asymmetrically encrypt the symmetric encryption key using the provider's private (asymmetric) key! The (asymmetrically) encrypted key is then usually attached to the (symmetrically) encrypted payload.
The consumer (and only this one consumer) can then decrypt the encryption key using his own private key and use it to decrypt the payload.