This is not about using DataSets. It's about knowing what happened with an entity.
Suppose you want to edit an 'Aggregated Entity', like an Order, with header and details. You want to do it in a multi-tier application. The application retrieves the order using a service, the user changes something in the header, deletes a line and adds another line. Now you want to save the changes.
First, you need to know what happened in the client. You need to know a line was added, another modified, etc. You could also need to know the previous values for optimistic concurrency checkings. You need a change tracking mechanism. You can use the DataSet or a custom one, but you need one.
Now, we need to send those changes to the server, together, because I want them executed in a single transaction. I cannot have a service called 'ModifyOrderCustomerInformation', another 'AddALineToOrder' and 'DeleteLineFromOrder'. I need an 'UpdateOrder' service. You can use a diffgram to do it, or you could build your own change-serialization mechanism.
So, I really don't see how you can build an application the way he suggests. It's very nice from the 'service' point of view, but it's very difficult from the client point of view. The only way I see is to map the UI to the service interface, so the user can 'Change Address' or 'Update Marital Status' as different operations in the UI layer, but I can't let the user 'Modify the Customer'. It's a lot of work, and I seriously doubt that the users will like it.
Additionally, you need change tracking even for web apps. If you want to 'edit an order' using an Aggregate, you need the whole Order, you need to have the Order somewhere (session/viewstate) while you edit it, and you need to know what happened. With the Entity Framework you will need to manage it manually, as David's post suggests.
Even if Udi is right, and that's the way applications should be built, I doubt most mere mortals in Earth will want to do it. It's too much work, just for not 'sending the changeset'.