nevents have the event id already, and they can have the author pubkey there too for more future-proof hinting. Relay hints serve as a good-enough hinting mechanism not only for fetching of that event immediately, but also for associating those relays with the pubkey that authored the mentioned event in a client store -- those associations can later be spreaded around and help other clients that are having trouble fetching data from such pubkey, but they can also update over time. 

 It remains true that in a distant discrete future just the event id will do nothing, just as hints to dead relays won't help, but in a continuous timeframe in which the entire network reads these relay hints, associate them with pubkeys and proceed to update their internal "outbox score" everybody goes forward in time better equipped to make sense of all the mentions.

Oh, also event mentions often come with associated "p" tags, so if a client has some clue about where to fetch events from that pubkey they can use those to try to find the mentioned "e" even if all its relay hints are dead (I guess this is also true for note1, but note1s are not helping anyone build all the required understanding in the meantime). 

 I realize I just wrote a bunch of garble, but this is what I mean: https://how-nostr-works.pages.dev/#/outbox 

 That's a nice resource. A clear way of visualising it. 

 when sound button?  

 Clients should always update the relay hint (both on tags and on bech addresses) when creating events (don't just copy/paste what was there or what the user inserted). Good Nostr architectures log all relay hints seen for each event id, so that if it needs to load the id, the app has multiple options. When writing, apps should update the relay hint to the latest NIP-65 relay the author of that event is using IF that relay has the event.