Nice 
You’ve correctly identified where the slowdown occurs, and fixed it.
In a “DO” statement, the return value is optional. In line 73:
((>= start duration) T)
the “T” is superfluous. You can use:
((>= start duration))
Generally it’s better to avoid single character names for variables. Short but descriptive names are nice and definitely help with bug fixing if you have to come back to the code 6 month or more after you’ve written it.
Now that the “window” function is not really a “window function”, it may be better to rename it.
I also wonder whether, with your new approach to the task, whether amplifying each “window” by a constant gain gives the best results. Perhaps worth looking at whether the results are better if the “gains” controls extrapolate linearly from one gain level to the next rather than moving in “steps”.
Using the raised cosine window (in the original code) was really just a quick and dirty way to smooth the gain changes (and it works surprisingly well). It could be worth looking at other ways. One method that is commonly used is for gain increases to be linear and gain reductions to be exponential. I recall that another Nyquist compressor effect fits parabolic curves to the peak measurements, then uses the curve as the variable gain control.
Probably worth noting that even with your (good) optimization, there is still a practical limit to the length of audio that may be processed in one go (look at memory usage while a long selection is processed). We don’t yet have a good solution for that (see this post for background information about this issue: https://forum.audacityteam.org/t/rms-measurement-for-large-files/41589/1).