The issue you raise is valid and I think it comes from the misunderstanding that even most nostr app developers have about the protocol which leads to them writing "nostr apps" in a way that - indeed - makes no sense, causes confusion, and ultimately does not solve anything.

In one short sentence: people mistake nostr for IPFS. They think relays are there to somehow store the events, to provide persistence. They are not! They are there to relay the data. Remember, the T in nostr stays for transmitted.

Most "nostr apps" do this: want to publish an event? Let's blast it to a list of relays and say done! Want to see other people's events - or even my events? Ask the same list of relays. Maybe have a DB locally used as a cache for better performance. This is the wrong approach in my opinion, and leads to nostr being misunderstood - at best - and will lead to data loss and pain and disappointment in the long run.

To better explain: I think relays should be thought as ephemeral entities. Every client should store the data locally first. After storing the data locally, it should blast it to a bunch of relays that happen to be active at that particular moment, and other clients will receive these events from those relays. But these relays might disappear an hour later. They are not there to stay. Having the data locally means that IF the user decides that the events are important enough (for example the events represent profile metadata or long-form blog posts), it can periodically send them to new relays. If the events are not considered important - like a short status update - it is perfectly fine to just stop caring and assume that whoever got it, got it, but other clients that come online later might not get it anymore.