I think we ought to consider notification expiry as an optional attribute for notifications as well. This would certainly be helpful for notifications about things which are likely to become irrelevant soon. The primary use case here would be any kind of "system messages" (the types of things we might use CentralNotice for). But it might also be an alternative to bundling for high-frequency notifications about watchlist updates, talk page responses, etc. I'm not sure how useful a bundled "There are 345434 edits to 3433 pages on your watchlist" notification is.
Topic on Talk:Notifications/Flow
I agree on the principle, although not everything should expire. For instance, the page gives reverted edits as an example: even after months, when they're no longer in the RC table and in the watchlist, if I've not reviewed the revert, I should be able to know about it. On the other hand, notifications about years-old discussions are probably useless because they're no longer relevant.
With regard to your example, though, I don't understand: is it random, or is this notification system (in the new special page) supposed to replace the watchlist? If this is the case, I suppose it's also meant to serve as a global watchlist?
Serving as a "global watchlist" isn't the effective purpose of the design but it ends up being a side-effect.
Notification expiry times would be of great assistance to some experiments we're thinking of running in E3. Many potential asks about task recommendations or similar stuff are simply not relevant after very long.