If you’re using zero-based indexing (which it seems you are) then 199 is the correct number to use in your calculation, because when the scale_factor is 1 the index should be the last sample, and if you’re counting from 0 then 199 is the 200th sample. The “gaps” reasoning doesn’t really make sense to me, but the number should be fine 
My bad - I forgot to flip the fraction apparently. I’ve updated the equation in my comment, but it’s the same as yours anyway (just in one step instead of two).
Peak finding finds maximal values, not steep slopes (i.e. the peak is on the signal, not its derivative). Consider that a cliff at the bottom of a mountain may be the steepest portion, but it’s not the peak. Presumably that approach helps avoid large variability when trying to detect soft riverbeds/sea floors that may have a slow and smooth density gradient.
I’m unsure what the algorithm does when faced with a saturated signal (a peak with multiple full intensity values in a row, giving a flat top) - it may choose the first top value, or the middle one, or may use the derivatives to try to estimate where the actual top is most likely to be, or something else. Saturated signals are very difficult to calculate meaningful results from, because there’s a lot of missing data (it’s like looking at a photo of a mountain, but the top is cropped off - how can you tell where the peak is?).
If you’re getting a lot of saturation (which looks to be the case in your plots) then it would be helpful to reduce the gain, and/or reduce the transmit duration. It may be worth turning on auto_mode, but if that’s already on then it seems to be performing somewhat poorly for your use-case, in which case you should try switching to manual mode (disable auto_mode), so you can set a more appropriate gain manually. Note that in manual mode you also need to control the scan range yourself.
As a note, if you’ve found and tested some alternative algorithm that gives more accurate distance estimates, you can of course apply that on the profiles in post-processing and use those results instead - it just won’t necessarily agree with the estimates provided by the sonar. You’re also welcome to share and discuss algorithms here if you’d like to