Someone is on a slow computer.
169.99$ chromebooks run most every site fine.
Someone is on a slow connection.
Controlling your rendering process and minimizing your payloads solve this.
Someone is on a phone, i.e. a slow computer with a slow connection. Most Smartphones after an Iphone 4 can Run the aforementioned example without blinking.
Someone is stuck with an old browser on a computer they don’t control — at work, at school, in a library, etc. The first 2 years of my career was working in the Health IT landscape, where IE7/8 on the worst computers were king. We still managed to build a reactive DnD interface. It can be done.
Someone is trying to write a small program that interacts with your site, which doesn’t have an API. I don't get this one.
Someone is trying to download a copy of your site to read while away from an Internet connection. I would argue that sites like twitter don't want this. They want your data. Stuff isn't free.
Someone is Google’s cache or the Internet Archive. You can detect this
Someone broke their graphical environment and is trying to figuring out how to fix it by reading your site from elinks in the Linux framebuffer. If you are trying to read a site from the Linux framebuffer you probably can fix your graphical environment. Or you probably have a smartphone/spare machine, or both.
Someone has made a tweak to your site with a user script, and it interferes with your own code. I would argue the same can be said with static sites if they interfere with the rendered markup.
Someone is using NoScript and visits your site, only to be greeted by a blank screen. They’re annoyed enough that they just leave instead of whitelisting you. I would argue the percentage of NoScript users is even less than people who are still using IE7.
Someone is using NoScript and whitelists you, but not one of the two dozen tracking gizmos you use. Later, you inadvertently make your script rely on the presence of a tracker, and it mysteriously no longer works for them.
You name a critical .js bundle something related to ads, and it doesn’t load for the tens of millions of people using ad blockers. Then that's poor coding by the ad blocker. It should be actually seeing what the code does, not making judgements based on filenames.
Your CDN goes down. The entire CDN? That's unlikely. What's more likely is my house catches on fire while I am getting struck by lightning and a cosmic gamma ray hits my smartphone directly on the chipset and flips a bit which causes it to segfault so I can't unlock it and I can't call for help.
Your CDN has an IPv6 address, but it doesn’t actually work. (Yes, I have seen this happen, from both billion-dollar companies and the federal government.) Someone with IPv6 support visits, and the page loads, but the JS times out. Switch to a better CDN.
Your deploy goes a little funny and the JavaScript is corrupted. Then your tests and QA process should catch it before you make the site live, otherwise you should rollback and try again.
You accidentally used a new feature that doesn’t work in the second-most-recent release of a major browser. It registers as a syntax error, and none of your script runs. See above
You outright introduce a syntax error, and nobody notices until it hits production. See above