Just a quick follow to say thank you for your helpful suggestions.
For those unfamiliar and curious, AtoM is a web based application that stores user data in a MySQL database, using PHP to serve the end user templates in HTML - you can learn more about the application and its architecture here: https://www.ica-atom.org/doc/What_is_ICA-AtoM%3F. Because everything is managed via a simple GUI and storage can be linked to an archival description, there's no need to update the finding aids when physical location changes - merely update the physical location and the information is already attached to the archival description.
As for security, we have considered this in the way that end users can access our EAD, and will be allowing archivists to hide information they do not want included on export (this option is already available in our GUI via the "Visible Elements" settings, which can hide certain fields for non-authenticated users). Regardless, for many of our users, EAD is their preferred, standards-compliant way to migrate information between systems, and because it is possible to encode these fields within EAD, we've chosen to do what we can in our application to allow users to include this information in their exports when they want it.
Best practice implies that users are applying physical location and container links at the appropriate level (file or item, for example), which would avoid the problem edge cases that initiated this question in the first place. However, the real world, and what people want, is often different from ideal use, and we are trying to accommodate an international user base with very diverse interests, intentions, and use cases, while still conforming to best practice as much as we can.
Michael, thank you for the reminder about the <title> element! I have come to working on this issue based on what we had in place prior to my revisions, and am not sure when the <title> element was added - I've noted that in EAD 2002 it is allowed within <container>, but you are correct it does not conform to the element's description, and does not seem necessary in any case. I've been so focused on working out the relationships that I had not yet had a chance to review this. Good to know as well that this will be one of the changes coming down the pipe with the current revisions. I will be recommending to our developers that we remove this element from our physical location module. Personally, I do think that keeping @parent included in <physloc> is useful, for the exact use case that you suggested (several shelves within a range, etc.), so I am also glad that my question has inadvertently provided you with a use case for its maintenance.
Once again, I appreciate the time everyone has taken to respond to this issue, and the speed at which it has been addressed. Likely we will look at referencing physloc/@id in container/@parent to solve this problem - I can't think of a use case where a single container would need to reference more than one physical location - our problem has been moreso with associating one or more containers with a specific physical location, which this should solve.