This seems to be a touchy issue, but I think that it is important one and I
would like to promote an objective discussion with those who are interested.
The reasons why I believe that you should use client side proxies and
instantiate remote objects using the new operator wherever possible are as
follows:-

#1 Less code is required and it's simpler.
#2 The overall footprint is smaller.
#3 You do not need to code, maintain, document and support bespoke
configuration methods.
#4 Changes to the remoting framework will not break your code and may
improve it.
#5 Supports location transparency, including in-process activation out of
the box (to the extent that it is possible) which has been a design goal of
every remoting framework that I have ever come across, including COM and Net
remoting.
#6 Tightly integrates with .Net versioning out of the box which I again
believe is a design goal of remoting in .Net. In fact to quote the MSDN -
"Remoting was designed to work with strong-named assemblies."

The latter point may become crucially important as we move back towards
'smart clients'. Side-by-side running will be critical to the avoidance of a
distributed version of the so called 'dll hell'. Client side proxies allow
granular control over which clients bind to which servers, even over the
same end point. Of course, in a perfect world, we would not have to
anticipate any versioning issues. A v1 client accessing an interface from a
v2 server should get the same service. But we do not live in a perfect world
and there may be other reasons why you might not want a v1 client accessing
a v2 server. Perhaps the v1 client has not yet paid for a v2 service.

I have seen a lot of reasons put forward for not using new to create client
side proxies from various sources. However, it is not clear to me that they
have been entirely convincing.

#1 You need to distribute implementation assemblies:- This is simply not
true.
#2 Soapsuds strips implementation from serializable objects:- But you can
put them in a separate assembly.
#3 You cannot remote typed data sets:- I have not tried, but why would you
want to? Wouldn't the performance hit be onerous?
#4 Various bugs with soapsuds:- I have not been able to replicate the ones
that I am aware of. Maybe they have been fixed. Perhaps there are others.
However, if every piece of software which had a bug was abandoned, we would
not be programming on a Windows platform right now.
#5 Interfaces promote good design:- True, but then again, you are not
precluded from using interfaces alongside client side proxies.
#6 Location transparency is dangerous:- Well, as I have already mentioned it
is a design goal of every remote method invocation technology that I have
ever come across, including, I believe, .Net.
#7 It's cumbersome to code:- Maybe, but a minute or two adding a build event
to the server assembly project does the trick. No doubt future versions of
the IDE will hook things up to generate the proxy code for you the way ATL
did.

So there we are. I realise that I am risking my neck and the associated
wrath of some posters here, but I am genuinely interested in trying to get
to the bottom of this issue. Of course I am not saying that there will not
be circumstances under which using a client side proxy does not make sense.
But I believe that the use of the new operator on a client side proxy should
be the architecturally preferred scenario. I would be very happy if an
objective argument could be constructed to the contrary.