If you have a password and don’t use encryption, then the data is still stored in the clear, so it would be accessible to anyone who parsed the Reflect file. Theoretically, the Reflect application could even be hacked to simply skip the password prompt and allow access to the data in this scenario. That's why you should absolutely use AES encryption, in fact I have a Wish List thread asking encryption to be made the default and for the “no encryption” option to be removed, or at least come with a warning if it has to be kept for compatibility. A backup that has a password but no encryption imparts a false sense of security to the user, which can be very dangerous, and I can't think of a single use case in 2018 for having a password but no encryption. CPUs for roughly a decade now have had hardware acceleration for AES encryption/decryption operations, so there's little to no performance penalty for enabling it, but even if there were, that consideration should pale in comparison to the risk of losing sensitive data, especially for backups involving other people's sensitive data. Companies in certain industries that store sensitive data about their clients are required to notify those clients whenever the company has reason to believe the clients' data may have been compromised. Loss of an unencrypted backup would certainly qualify as such an event, and could potentially require the company to notify ALL of their past, current, and prospective future clients. However, those companies are typically NOT required to notify anyone if the lost data was encrypted, since in that case the lost data isn't assumed to be compromised -- so whether or not the company's backups are encrypted can drastically affect their reputation after such a loss, and of course their customers/clients susceptibility to identity theft, etc. There’s simply no good reason not to use encryption in a scenario like this, in fact it's so easy nowadays that NOT using it would probably expose whoever configured the backups that way to gross negligence lawsuits.
When you DO use encryption, neither Reflect nor anything else can access your data without knowing the password/key — so let’s talk about that. If you lose control of an encrypted file, then assuming you haven’t also lost control of the password of course, the safety of your lost data depends almost entirely on password length and complexity. An attacker might try some easy guesses first, such as words in the dictionary, so make sure your password isn't that simple, but after those are exhausted, they switch to brute forcing the password. Technically the attacker could try brute forcing the AES key directly, but even with a 128-bit key, that would take on the order of hundreds of millions of years. So your goal is to make sure the password is ALSO impractically long to brute force. There’s a useful interactive tool here that puts some actual time figures on this concept and shows the impact of adding length and/or complexity: https://www.grc.com/haystack.htm
As you can see, adding even a bit of length increases time to brute force dramatically, which is why even a simple long password is better than a short, gnarly, impossible-to-remember password. For passwords that are vulnerable to offline attacks, as in this case, I typically use at least 16 characters. Easy ways to add length without making a password difficult to remember and type would include adding a phone number, a few zip codes or significant dates, some easy pattern of characters, etc. Again, a password doesn’t need to LOOK scary to be secure. If an attacker is brute forcing, then length is the only thing that really matters. In another thread around here I explained why a password of 50 zeroes in a row is far more secure than something like “1icYZe0X60XAig”.