It's interesting that TimB is detecting the surge of message-ness in everything Internet lately. Obviously he's been involved in many software systems and knows lots about messaging and when his radar picks up on something it usually means massive momentum in this area is underway.
Of course, lots of people have been saying this - my blog is sub-titled 'Messages Bouncing Around' for a reason - as well as actually building software and designing systems with just this in mind.
I enjoy building software and designing systems around message based approaches, but I also enjoy talking about the 'big picture' of messaging - so forgive me for the following ramblings.
Undeniably messages are everywhere, but when Tim Bray talks about 'a feed is just a little bundle of messages' I have to mention that a document (or document fragment) does not equal a message. I always associate an operation with the blob of data - for example, a feed could mean 'please remove from your site entries that match exactly the following items...'. Or it could mean 'please add to your site the following items...'. And so on.
Tim goes on to think about what happens when everything is a message and everything is asynchronous. Look to the Web for an example of a system where everything is a message. As for asynchronous, that means different things to different people. One aspect of asynchronous is 'unsolicited requests'. Email is a set of unsolicited messages (demanding your attention, which is a scarce resource). Requests into a Web server are unsolicited - they happen at any time, usually not of your choosing.
Some scenarios where people usually desire 'asynchronous' messaging on the Web are long running operations, disconnected use and events to the desktop (or palmtop or phone, etc).
Long running operations and disconnected use are somewhat similar. The need is for a reply to be delivered in the face of a network connection failing. This requires correlation between a request and a reply. The Web uses the network connection to implicity do that correlation - but there are hooks to grow into other approaches, they just haven't been widely used or standardized (see the '202 Accepted' HTTP response).
Delivering messages to the client means allowing unsolicited requests to be sent to the client machine. This means putting a Web server on the desktop. An example of this is Google's Desktop Search. Once Google opens this up through the firewall, you will see Blogger notifications and Google Search Alert notifications streaming to your desktop via HTTP and the Google Web server they've sneakily installed. People trust them and will continue to allow Google to expand their footprint on the desktop. The sky's the limit when you own the ground people walk on.
Unfortunately, allowing unsolicited requests has it's downside. Web servers get this in terms of denial-of-service attacks, and people get this in terms of e-mail spam. Authentication will delay this a little bit, but there will always be a constant battle between letting information find you and hiding from spammers.