If anything, modem users would benefit from a client side solution. Only sending raw data to the client and then doing all the processing on the client would drastically reduce the bandwidth use. The initial page view might take a bit longer as the client side scripts are downloaded, but then the browser cache takes over.
True indeed, to the point where the user quit the waiting because it's too long. Below that point, all good. Hence the "loader on demand".
On that "point", on real everyday use of the web, it's very hard to determine, especially from your point of view (delivering software). You have to take into account the things a "basic webmaster' want to add, the others broad basic pre-requisites scripts (like IE7). Not much margin to work with.
The biggest performance problem on the web today is unsufficient server performance. Have a look at your CPU usage while browsing the web. It hardly ever goes over 10%. If we could utilize this idle processing time, webservers could go back to doing what they do best and that is to serve content.
Again, I agree on the theory; not the idea that could be done with nowadays protocols and standards. But I could be wrong, for example I don't know the bandwith and server consumption of XUL.
And there is another trouble with wide and heavy client side, that's new hardware client. Let's take commons forum features, and say put half of them client side. Are you sure a pda or a pocket phone can handle that much ? They will, someday. But right now, you add an item of worry for webmasters. They have to worry about browsers bugs, plateform bugs, end-user needs (as in real, actual and reasonnable ones) and desires (as in futiles useless gadgets), faulty or cryptic writing of standards, server bugs, user hardware, user bandwith, server bandwith, and I forgot some. Adding user cpu power at hand ? Ouch ^^
Who would be reading your e-mails? Google?
That's what they do to target ads Email is cheap, storage too, I don't see the needs for gmail. I admire their implementation of mail threading (something Qualcomm did iirc but never implementend on Eudora, I still don't know why), but that's it. I don't use webmail or IMAP, so I don't need 1gB, and if I did use IMAP that would be quite ridiculous (I have around 600mB of emails, not counting attachements, that's several gB with them). But that's me, if some people need to save $2 or $3 to have a decent email provider that's there choice :-)