The RAR5 archive format encrypts file data using AES in CBC mode, and generates a 256-bit key using PBDKF2-HMAC-SHA256 (32768 iterations default?).
If an attacker is able to view many files encrypted this way all with the same key, the attack is to recover the key from the ciphertext. This is not an easy task, even if the IV was reused. In WinRAR, the IV should be pseudorandom, preventing the same (or similar) plaintext from generating the same ciphertext blocks.
Additionally, a 128-bit salt is provided during key generation, which should prevent the generated key from being the same for 2 different archives, even if the password is the same. For decryption the salt is extracted from the archive header.
While there is no documentation I can find that specifically says the salt and IVs are pseudorandom, I would assume that it is, meaning that for a given file/password combination, the chances of the archive ciphertext being the same are near 0.
Clarification from RARLAB on exactly how they are generated will help. In the windows UnRAR utility, there is a fallback from CryptGenRandom to using the system time to generate random bytes, which is not acceptable during archive creation, but may be reasonable during decompression for whatever reason. Password data is encrypted in memory and cleared using appropriate methods. I also find it curious why there is a separate salt value in the file record header, as the one in the archive header should be used for KDF.