A remoting client need not register a channel (if its http or tcp) when making a remote call. The remoting infrastructure will load an appropriate channel after looking at the scheme of the URL (tcp:// or http://). Though being explicit in code is goodness for the channel case it can lead to unwanted results in some scenarios, eg. If the client is hosted in a IIS vroot and it doesnt have control over other components which might be loaded in the same appdomain. Though you could protect against channel registration failing by giving your channel a unique name, you should be able to get away with not registering one at all.

I have also seen code which registers a new channel on each remote call. This is certainly a bad implementation. The cases where you need to register a client side channel is:

 - when you expect callbacks and you need a listening channel on which server can callback on.
 - you need to customize the channel to add properties which dont exist on the default channels. Like proxy settings for  HTTP
 - you have your own custom channel

Its also desirable to configure channels through a config file than code, so you could change channel usage without recompiling. Also make sure channels are only registered during initialization and not on each call.