For that reason, the usual trick is to use asymmetric encryption to protect a symmetric key (a fresh one per payload) that is then used for the actual payload. That way you get the speed of symmetric encryption with the benefits of asymmetric ones.
(Though evidently that's not what the PS5 uses here, otherwise it would be useless to read out one symmetric key).
As your sibling post technically notes, asymmetric vs symmetric is a wash, here. To use asymmetric encryption for saves, the PS5 would need to know the public and private keys, so you would be able to extract those and still have the same access.
Of course, there are still advantages to having the symmetric key not be used as is, but there are many solutions other than asymmetric encryption.
And to add to that: you should use as many different symmetric keys as possible as long as asymmetric decryption of the key doesn't overly degrade performance.
First of all, we are talking about on-device decryption, so there is no difference in terms of security whether people extract a symmetric secret key or an asymmetric secret key.
Secondly, yes, asymmetric encryption is slower, so you almost always use hybrid scheme: asymmetric scheme (ElGamal, for instance) for encrypting the symmetric key, and then a symmetric scheme (e.g. AES) for the bulk of the data.
Only in very exotic protocols such as digicash blind signatures or anonymous credentials with "algebraic MACs", you want your actual content encrypted directly via ElGamal or RSA, so that you can do some operations or proofs about the ciphertext — in those cases you can't encrypt symmetrically as that would erase all the algebraic relations.
> First of all, we are talking about on-device decryption, so there is no difference in terms of security whether people extract a symmetric secret key or an asymmetric secret key.
Sure, but we might (potentially) be interested in the encryption part later on too, and having a symmetric key will make that easier (though of course it won't get you past any signature checks.
I've never come across those more exotic protocols, but I'm familiar with symmetric kex under public/private encryption.
The most common asymmetric encryption algorithm (RSA) can only encrypt a plaintext of limited size. Depending on padding scheme, a 2048 bit RSA key can encrypt a message of up to ~245 bytes.
Typically to securely encrypt a message you use symmetric key encryption. Then to allow a third party to decrypt that message, you encrypt the symmetric key using the third party's asymmetric key.
Symmetric keys means that anyone with the key can do everything the key allows one to do. That's bad if you're building consumer devices that contain the key. Signing with public key cryptography, which allows only verification with the end-user key, is much more secure in this scenario.
This isn't a good answer for "Why don't they use asymmetric keys for everything?" as you basically just explained that it would be more secure to use asymmetric keys.