Using callbacks is fairly orthogonal to the document model - you can have a fairly imperative/callback-based web application, and a number of modern desktop GUI toolkits seem to be taking a "UI as a function of state" approach. If you just do vanilla web development (or even classic jQuery), you'll be writing a lot of very imperative, very callback-based code manipulating the widgets sitting in situ in the DOM. So I don't think the functional style is a feature of the document model per se, just a popular idiom that was started in web application development.

The lack of widgets is a fair point, but again, I don't know that that's specific to a document model over any other model. It's more that browsers have been historically poor at providing high-quality native widgets. A lot of other desktop frameworks provide very limited widgets too!

That said, I'm not sure that native widgets are the be-all-and-end-all here either. I like the example of the Ryanair flight date picker - it's essentially a custom widget, but it is really effective for the job that it does. You can easily select a period of time (typically with conventional date picker widgets this is done with two separate input fields and two linked date pickers), but you can also provide extra information inside the picker, so the user can see quickly whether it would be cheaper to fly out a day earlier or later, without having to try out a multitude of different dates.

This would be a terrible widget for a native GUI toolkit, because it's so niche - it is relevant for a handful of travel related applications, and that's it. It's also difficult to imagine a clean way of creating a single date picker widget generic enough to handle all the different use cases involved. But because the web is built out of a lot of very flexible building blocks, it's very easy to create new, very specific widgets. (And yes, they won't look like native ones, but I'm not necessarily sure that's a huge drawback for me. I know it is more important for others, though.)