The restriction issue is an additional point, which remains valid for any user interface. I would only start by simplifying the way relays are exposed to the user, but not blocking them if they want to make more complex configurations.
Discussion
No, because if app can't figure it out by itself the UI teach the user to do it.
If we convert to your idea now, nothing is going to work because people will just add nostr.wine to the list and will never receive a notification.
How is the situation different today if you add nostr.wine to both incoming and outgoing mail, or flags both read and write, because you don't know the meaning of the terms and the implications, and then as is typical you turn everything on “to try if it works”?
Since nostr.wine requires auth the app might explain that this relay is poorly suited as a general inbox, but it might still be useful for users registered with it, and then suggest adding another public one, or disabling it as the inbox (read).
nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c recently added a relay testing tool that could be a good example of how to direct the user to the most appropriate use of relays.