Before the scrollend event, there was no reliable way to detect that a scroll was complete. This meant that events would fire late or while a user's finger was still down on the screen. This unreliability in knowing when scroll has actually ended, led to bugs and a poor experience for the user.
The best this setTimeout() strategy can do is know if scroll has stopped for 100ms. This makes it more like a scroll has paused event, not a scroll has ended event.
A reason this event took so long to come to the web platform was due to the many small details that needed specification details. One of the most complex areas was articulating the scrollend details for the Visual Viewport versus the document. Consider a webpage that you zoom in on. You can scroll around when in this zoomed state, and it's not necessarily scrolling the document. Rest assured that even this visual viewport user driven scroll interaction will emit the scrollend event once it completes.
If you're looking to use this new event now, here's our best advice. You can continue using your current scroll end strategy (if you have one) and at the beginning of it check support with: