> Thinking of good examples is considerably harder.

It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use IntersectionObserver and usually with simple abstractions around that.

> In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading

Yep that was my side eye.

> And since lazy image loading can now be accomplished without JavaScript, I'm not sure what still needs to be lazily loaded via scripts watching scroll behavior.

Lazy image loading in HTML was controversial too, because it can be used for said shady tracking. But other deferred loading/execution is extremely helpful (for users!) for below the fold interactive content which doesn’t ever need to load if the user doesn’t scroll and doesn’t need to run until it’s nearby, even if the user wants to interact with it. Large JS payloads are a huge part of why sites feel unresponsive when they load. Even if they’re ultimately what the user wanted, it’s valuable to deprioritize the code they don’t need yet.

> Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.

The most common is client-side routing (even turbolinks which are popular as an alternative to SPAs), but also any interactive content without stable heights.

> Scroll-snap: The examples on MDN don't even behave properly

I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)

> Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.

That’s all fine and good, but there are cases where the offset is useful and small and users benefit from both.

> These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers

The fact that the most benign uses of them is so opaque is a testament to how well the newer APIs are designed, they’re so close to invisible that you’d need to be paying close attention to their usage and limitations to even know how they benefit users and how widely they’re used. I didn’t know about most of them and how they’re used either until I was on a MDN hyperfocus just learning what had been introduced while I was fully backend. Since then I’ve seen incredible UX improvements specifically leveraging IntersectionObserver to make sites a lot more usable, often at the library/framework level where most devs have a happy path to just do the right thing. I know that sounds antithetical to the common anti-JS rhetoric, but it’s been so effective it’s almost invisible.

Unfortunately the worst cases are still terrible so I can’t blame you for your reaction at all.