If you are dealing with encryption using user-provided passwords, the resulting ciphertext might be attacked using a "dictionary attack", that is somehow the same kind of attacks we are trying to mitigate using a salt to store the passwords, but not completely.
When encrypting with user provided passwords, the KDF is used as a mean to compensate for the poor entropy of the user passwords, but because you cannot consider the salt to be a secret and you have to provide it to the decrypting party in some way, if you use a salt, you risk to simply use a constant one, which changes not much or a password-dependent one, which also is not the goal of a salt, since the dictionary attack against encrypted data would still work by simply using the same parameters and salt as you do.
So in the end, you should be worried about making the dictionary attack as costly as possible and this is possible with modern KDF such as Argon2 or Balloon, where you can set the parameters, which can be publicly known, in such a way that the attack will be too time consuming and costly for the attacker.
So effectively, I agree with you that the salt is not necessarily useful for your use-case, however your use-case also mandates you to use a KDF designed for such cases, not just a hash function.
PS: notice that dictionary attacks are only useful when the adversary is able to tell easily whether she has found the correct key or not. Which is typically the case in known plaintext attacks, but not always true for all use-cases.
PPS: I'm not mentioning the pepper since you're aware of its existence given your other question. But a pepper is typically useful in that kind of use-case. Note that the salt, when considered secret is basically a pepper.