If you feel comfortable and productive in WCF there may not be a strong reason to use anything else. I certainly think that WCF is a good place to start because if you follow its contract pattern it is an easy pattern to convert to work with other systems, should that need arise.
For one of my own projects, I started with a WCF prototype. When I started into "the last mile" I found that more often than not I was fighting WCF to get things done. I was particularly having issues with game matchmaking in WCF's peer-to-peer stack, which didn't quite give me the tools that I needed. In that project I ended up switching to XNA's network library, which gave me the Xbox-like matchmaking (and GamerTags and whatnot) that I was looking for and (badly) attempting to emulate in WCF. (Of course, XNA's networking library assumes you are working in an XNA game, and unfortunately still doesn't support publishing the game on Windows without a GfW Live contract.)
I didn't touch that much of my networking code in the switch from WCF to XNA Net, because the contracts themselves (the interface classes) didn't change all that much (other than dropping the WCF attributes). Writing Reader/Writer classes that implemented or consumed my contracts was fairly straightforward. I probably could have kept support for both with a little bit of
#if WINDOWS mangling, but I had decided to just drop WCF support at that time, because it simplified things on that project. Perhaps interesting, in starting other projects directly with XNA Networking, I've still been using something of WCF's interface/proxy-driven "contract" pattern. I've been meaning to write a blog post on that subject, actually, because I think it is a good pattern to follow.