If your service could potentially ever talk with clients that you do not control, WCF DS (and therefore OData) should probably be you're choice, since your service will be far more inter-operable than anything else by being part of the growing OData ecosystem.
If you don't care about any client but your own, then you are presumably basing your decision on ease of development, performance, maintainability, and so on.
A straight WCF Service will give you more precise control and can likely allow for performance enhancements in various ways, since you have a lot more control over what your data looks like. But it probably means more work too.
WCF DS Server/Clients will make you never have to worry about serializing or deserializing data to the request or response. WCF DS Client can build many types of requests and has entity state tracking for free. The server is quite easy to get up and running if you're using the Entity Framework, too. If you need to do something that isn't in OData, it might be difficult to using WCF DS, depending on what you need. There is a lot of momentum in using Web API for this sort of thing as well - check out Web API + OData for your service as well. If you went that direction, then you'd want to still use the WCF DS Client.
Bottom line: WCF DS will very likely be faster to get you up and running with a lot of features you will likely need. But if you end up needing some custom logic that the stack doesn't handle, it will be harder to work in than a straight WCF Service.
Note that WCF DS Client has a 5.6.0-alpha .NET Portable Library available (prerelease) right now, which will support both Windows Store and Windows Phone 8 Apps from the same DLL. This is missing a few features that a phone application often needs, such as tomb stoning support. If this is a problem, consider using older releases (5.0) of the specific Windows Store and Windows Phone 8 versions of WCF DS Client.