I am not a "web developer" at the moment but rather into signal processing and I can only agree. Why is it so hard to just draw a pixel on the screen? Or why are there so many ways of doing it?
If you're talking in a general case, it's because it is actually hard. Send the buffer to your gpu, have it execute the command, send it to your screen which probably has a CPU of its own. Pushing a pixel is hard, and you have to do it 60 times a second. That's also why you don't just push a pixel but the entire screen at once. How hard it is for you depends entirely on the API. While Direct3D/OpenGL expose all the details, others like XNA or even Javascript's canvas do it rather painlessly.
What's really hard isn't pushing a pixel to the screen: it's doing it fast enough (i.e. same as your screen's refresh rate ideally) so that the user doesn't notice a visible delay. When 75% of the API is blocking AND you do work on the UI thread (Which is absolutely insane that browser developers haven't picked up this practice considering it's been advocated for more than 15 years on the native side of things), it's usually going to be visible.
To answer your question: one reason is that the developer needs to express how elements on a page place themselves not just on the screen but with respect to other elements as well. As you can guess, calculating this "layout" will occur pretty often, and if you have only one thread running all your code, then your logic and communication with the server can interfere with the rendering of the UI - thus making the response choppy.
On native apps, though some of them have borrowed web-type expressions of placement or layout, the entire calculation runs on a dedicated thread. Not on the same thread that also needs to respond to touch / slide / drag events!
HTH.