Basically you’re asking what’s the likelihood that the document will have been changed between the client previously reading the old value and the server processing the request to update to the new value - and this will depend on a number of factors - some of which are:
How long does it take for the previous document to be returned over the network from the cluster to the client?
How long does the client take to construct the new document?
How long does the request take to get over the network to the cluster node?
How long does the request take to be read and processed by the cluster node?
These are all going to depend on network latency, client speed, cluster load, etc.
With the information you’ve given it’s basically impossible to say. I suggest you do some measurements / experiments on your workload and environment and calculate what the likelihood is and pick a suitable retry count.
Alternatively you could test empirically and see how many retries you need in a representative test scenario.
So the additional piece of data I think you need is the average time taken to process an update.
Assuming your numbers, 100 comments per second on a popular post means there’s a comment every 10ms. You would therefore need to ensure that you can GET the “current” value of the document, insert the new comment and SET the new value back in generally <10ms to not be constantly fighting with other clients.