In this particular case I think it is not wise to introduce such a strict constraint on a retry number.
In the case of olm account we have only one account that can be concurrently updated per entire keyserver. Additionally updates are not expected to occur frequently. In the case of olm sessions however we expect frequent concurrent updates. Imagine a case of 10 people group conversation. If 9 of them send a message at the same time we might end up with up to 9 concurrent updates to the same sessions. Having const maxOlmSessionUpdateRetriesCount = 5; we will always experience a failure in 4 of them. One solution might be to parametrize this method with retry count and set it to the number of people participating in a conversation when this function is called. However I think it is quite cumbersome. I would rather drop a retry count constraint and start a time counter when this method begins. Each while loop round I would check current timestampt an calculate how much time has passed since the method was called. Limit would be put only on the total time we can spend working inside this method.

My intention to use smaller constant was that we expect olm sessions to be updated more frequently than olm account. Additionally there will be more concurrent updates at the same time. Therefore it is wise to wait shorter between subsequent retries.