Well there are more things to consider then simply just connection
pooling and interoperability.  Such as is this application going to be
just one part of an Enterprise application?  Will other applications
potentially be able to use your services down the road?  Do you expect
your infrastructure to always be pure Microsoft?  I agree with Cecil
that you can start small with client/server but between the layers I
would not use a Object Orientated Architecture.  I would side with a
Service Orientated Architecture, and this does not mean the use of web
servers necessarily.  Just make sure that you are passing the "message"
and not the implementation between the tiers, and you should be fine.
it is very hard to determine growth, but it is going to be a forgone
conclusion that technology will change.  With that do you feel more
comfortable using a vendor specific transport like remoting, or a more
common one such as SOAP via http (web services).  If you are looking to
longevity and if you ever forsee the need to be interoperable not only
between different vendor, but between different evolutions of a
specific.  I would create a client/server application with a "service
thinking" (SOA) approach.  .Net Remoting in my mind will only make you
re-write code down the road.