I think you might be mixing up two features here. One is deleting a message from your own inbox (this part about your email example makes sense).

The other is deleting a message that was sent to someone else from _their_ inbox. Which email does not allow you to do.

Except some clever people tried to implement this (notably Outlook and/or Microsoft Exchange has such a feature IIRC) where it sends another email to "recall" the earlier message. It's funny when you receive those recall messages in a non-Microsoft email client and on a different server than the Exchange sever they're using. I.e. you just ignore their request to recall and now you _really_ go read the message they're trying to recall, because it makes it _more_ interesting. Also googling this quickly it seems even if you stay completely within the Microsoft ecosystem it only works if the recipients didn't open the original email yet:

    With message recall, a message that you sent is retrieved from the mailboxes of the recipients who haven’t yet opened it. 

https://support.microsoft.com/en-us/office/recall-or-replace...

To map this to e-mail: if you receive an e-mail from me, and you delete it, but my e-mail infrastructure--the part on my end, not on your end--isn't sure I really sent it because the servers are flaking out and having tons of errors, and it retries the delivery, what would normally be an idempotent operation (because of how the e-mail you received twice will have the same message identifier) will cause the e-mail to re-appear... specifically because you have no record of having received it; and to make this even "cooler": if you use one of those dishonest "recall e-mail" features that people keep wishing existed (but not only can not should not), and the other side has already received both the e-mail and the recall, but the sender's SMTP server is still attempting to retry the messages, you will receive the e-mail, see it deleted, and then later see the e-mail again and see it deleted again. Is this really so hard to understanding? WhatsApp is nothing but an e2e event queue: it isn't a server that is storing data on your behalf... all of your messages are local to your phone, and with the exception of the shitty "delete for everyone" feature that WhatsApp implemented, your data is your data and the server knows nothing because it is just trying to deliver encrypted events on behalf of other people (who would, of course, own those queues, just like e-mail... but it is encrypted, so whatever weird mental model you have where this is somehow a bad thing terrifies me as to fix the weird issue you have would involve removing the encryption by adding permanent identifiers to queue objects that were visible to WhatsApp and then exposing to their server all of your otherwise-local message storage intentions).