We talked about such scoping rules in the past. However, that is not really necessary anymore due to anonymous attributes. When named attributes are used, we generally do want that they can be used outside of the current scope. That is why we name them in the first place.
In your example, you indeed have a name collision: A node group created by someone else uses named attributes and is accidentally overwriting your attribute. In that specific case, the node group should just have used anonymous attributes internally. If it wanted to expose an attribute to you, it should have allowed you to choose the name.
So, generally speaking, when you build a node group that others should be able to use without worrying about attribute name collisions, then you should not use named attributes inside the node group. However, when working at a higher level that is specific to your current project (or when you just want to get something to work and care about sharability later), it seems perfectly reasonable to assign the names you want to use with nodes (e.g. when preparing geometry for export). Named attributes are just a fundamental part of geometry to me, not being able to work with them in geometry nodes feels very limiting. As mentioned before, it would be possible to determine if a node group might be less sharable just by checking if it uses any generic set/get nodes for named attributes.