Super late to the party but I've been looking into this more deeply recently and I think there is a bit more to it then what I've seen in the answers and I think anyone else researching this subject might benefit.

1.) Key encryption does offer some theoretical security benefits when we are talking about large amounts of plain text data. It can be used to help mitigate exhaustion by rotating the key used to encrypt the data (DEK) and encrypting the DEK with the key encryption key (KEK) => envelope encryption. The encrypted DEK and data ciphertext are stored together. The idea here is that for very large data sets many DEKs will be used to avoid exhaustion and much fewer KEKs will be involved when designed correctly. This is useful for data at rest encryption (very common) and communication between endpoints with very large and sensitive traffic (more niche). AWS and google cloud services have APIs to support all this.

2.) The performance benefits can be realized even with symmetric encryption schemes. Some key derivation functions (KDF) used to generate symmetric keys can be very memory and processor intensive by design (ie certain Argon2 configurations). One could use keys derived from these type of KDFs as the KEK and use a cryptographic RNG (very fast) for the data key generation. In this case, it isn't really the encryption that is faster or slower but the key derivation. This is roughly how Windows BitLocker works (although I think they use PBKDF, not Argon2). Of course, this only applies to password based encryption but I thought it was worth mentioning.

NOTE: OP said "Then encrypt both the key and the file with public/private key." But only the symmetric key should be encrypting the plaintext (file). The KEK (public/private key) should only be used to encrypt the DEK. Otherwise you would see no performance benefit since you'd be decrypting the plaintext twice using both algorithms.