@bhavik.bhagat Good questions, happy to clarify.
First, regarding:
in the situation where messages stored in the system might contain zoom meeting info, do we have to remove that meeting info from the messages as well?
Yes, any Zoom info related to the user or account in question that is stored on your end should be removed as part of compliance.
As for:
As for point 2, is the approach mentioned in Deauthorization endpoint user identification - #7 by dave2 still suggested for our situation?
Yes, this is still a valid method for determining user/account.
Lastly:
Also in the case there is any problem with the deauthorization call reaching us, is there any retry logic on Zoom’s end? Do you have any recommendations on retry logic, like how often we should retry to send the confirmation if there is a problem on our end?
Zoom will try to deliver the deauthorization notification up to three times . The first retry will be sent 5 minutes after the initial notification delivery attempt, second retry will be sent 20 minutes after the first retry attempt and third retry will be sent 60 minutes after the second retry attempt for an event. If a 2XX response is received after one of these attempted retries, the deauthorization notification will continue to be sent as usual. However, if Zoom doesn’t receive a 2XX response even after executing all three retries, no further notifications related to that event will be sent to your app’s deauthorization endpoint.
We recommend utilizing a monitoring service to ensure the health of your endpoints. Should you ever suspect that perhaps your endpoint failed, you’re welcome to reach out to us directly to help confirm/troubleshoot.
Let me know if this helps. 
Best,
Will