Presumably just listening to the slider state and updating some global variables is fast enough to not need throttling, but I would definitely update the SVG DOM inside a draw loop running in requestAnimationFrame since there's no point in doing it any faster than that anyway.
I'm not an expert on high-frame-rate web drawing, but I've played with it a fair amount, and AFAIK there's no need to do any fancy debouncing logic beyond requestAnimationFrame.
A need may arise if a calculation took longer than a frame. (I’ve encountered this making a little programming language that generates graphics that updates in real time as you type. I’d imagine similar issues with web based latex-> pdf generators that update the pdf as you type )
If a calculation takes longer than a frame, then you’re going to stutter no matter what you do, right? I feel like the browser will do its best to let you interact with the slider between frames, but really I can’t think of a good way to have a smooth interactive UI with calculations that take more than a frame.
— edit: I see that I went off the deep-end, assuming that you were against using debounce functions in general. I now see that grandparent was conflating debouncing and not updating until slider comes to a stop. These are of course not the same thing. Apologies. I hope my comments on debouncing are useful to someone though.