Those are two totally different technologies:
Entity Framework is an OR mapper to make your database access easier; you can compare this to e.g. NHibernate, Linq-to-SQL, Subsonic, Genome, or other OR mappers
WCF Data Services is a way to expose your data models to the outside world over HTTP/REST; compare this to legacy ASMX webservices, pure WCF services, other service technologies
You cannot compare the two - they're totally different beasts, and in many solutions, they will be working together - one cannot replace the other.
If you have a console app that needs to read data from a database, you can either use Entity Framework directly - in that case, your console app must have a direct connection to the database, and it's tied to the Entity Framework technology.
The option of exposing the data using a WCF Data Service adds another layer - your console app doesn't access the data directly, but it just calls a WCF Data Service. Now you basically have two parts: your console app as the client, and some kind of a service app that will provide the data. In that case, your client doesn't need to know anything about Entity Framework or anything like that - you could also easily add a second client, e.g. a web app. But the service app that provides the data will still need to be able to directly connect to the database using Entity Framework.
So in the end, you're not really replacing Entity Framework with WCF Data Services - you're just adding another layer of indirection, but in the end, to get at the data, you still need some kind of data access technology (like Entity Framework).