Ye Olde Add Web Reference generates XXXAsync calls to services that use eventing to inform the caller that the call had completed.
Add Service Reference in something like a WPF or console app, when told to generate async operations, uses the IAsyncResult design pattern (BeginXXX and EndXXX operations). My understanding is that this was generally regarded as a step forward in usability and flexibility - you can use a callback, you can begin blocking at any point in time simply by calling EndXXX, you can group wait handles and block on a set of operations, you can poll, etc.
Why doesn't ASR in Silverlight use IAsyncResult? My guess is because the designers wanted to make it very clear that full asynchronicity is in fact required, and if they had used the IAsyncResult design pattern, it would have been too easy to try just call Begin immediately followed by End, which would have made for a stumbling block that would have been hit by roughly 100% of new devs or people who didn't have a good grasp of async.
The Silverlight team provided immediate access to the event based async pattern because it's an easier to use approach (but a lot less flexible). For example, the event is fired in the display thread, allowing developpers unwilling to think about their thread model to forget about it.
If you need better flexibility (as me), the Begin/End async pattern is available for Silverlight too. In fact the event based generated code is based upon the IAsyncResult one.
Your generated Channel interface defines the begin/end methods, and you can use the channel factory to obtain an usable implementation of the interface.