This could certainly be improved, but it is an edge case that applies only to PDFs.
PDFs are the one exception to the various Permissions rules in AtoM to deny access to the master digital object. This was hardcoded early on in the application as a sort of workaround - in general. if you are adding PDFs to your public-facing catalog, you want users to read any text that might be found in the PDF. However, the reference image generated from PDFs is a JPG that is generally just the first page, and too small to be readable. For that reason, early ICA-AtoM developers decided that, rather than adding custom rules just for PDFs, they would hard-code an exception for digital objects identified as PDFs so that AtoM won't apply the usual permission restrictions. This allows users to still restrict access to other digital object masters using the permission settings, without rendering the PDFs completely unusable.
This is also part of the reason that we use hashing when determining the digital object directory structure and final path to the master - to help obfuscate it. To be able to access a PDF as a public user that has been restricted as you have done, you need someone with access to the master digital object to give you the URL directly - it would take a lot of effort to brute force that link, and random guessing alone will not do it.
This means that the security risk is human - an insider with access helping to violate the established permissions by navigating to the master object, copying the URL, and giving it to someone who cannot log in themselves. We could certainly look to improve this in the future and ensure that the master PDF is fully restricted when there are also PREMIS Rights applied, etc - but in this theoretical security breach, why wouldn't the insider simply share their login credentials, or download the PDF themselves and give it to the public user, or help in some other way, etc...?
In any case: though low risk, I do agree that this should be fixed. While hardcoding the permissions to allow for the PDF exclusion is understandable (if not ideal) from an historical development perspective, it would be good to patch the case where specific restrictions via PREMIS Rights are applied, as this should not have the same exception.
I would also personally love to see the hard-coded rule about PDFs and permissions changed to a user-configurable global setting, as this seems a manageable compromise between the complexity of adding even more granular permissions to an already-overloaded module in AtoM needing an overhaul, and doing nothing. This would allow users with particularly strict security requirements to consistently enforce the digital object permissions for all object types, while still allowing others who want to configure permissions globally but still allow PDFs to be readable to maintain their current configurations.
In the short term, I have let our Maintainers know about this edge case, so they can determine how they would like to proceed.