Bruce Williams from the Indigo team has a nice walk through of the the XML elements in WS-Eventing.  When you strip away all of the namespaces and XML noise, it's a nice, understandable piece of work.

I like WS-Eventing because it's another tool in the architecture toolbox.  To me it suggests the end of polling in web service applications.  In some of the applications I've worked on today the client has had to poll the webservice to check for updates.  With eventing the client will be able to wait to be told if something has changed, rather than pestering the server like a kid in the back of a car on a long road trip asking 'are we there yet?' all of the time.   It's much more efficient to wait and be notified than constantly having to poll to check if something has changed.

I'm not 100% sure about how large corporates will handle security will work across the Internet and corporate firewalls.  For the client to receive the notification they have to have an open port that the notification service can send to.  Perhaps a solution is to use an approach like the MSDN SoapMail sample, where messages were returned to some central location, like a mailbox, which is polled by another service that picks the message up and forwards it to the client.  Perhaps the answer lies in the Security Considerations area of the spec which suggests the notification should be signed with security tokens.