From my perspective, the Data Services and their query approach is useful when querying simple object graphs from your server-side domain model. But when you want to query complex dependencies I couldn't create anything good out of it.
The classic DTO approach is fine-grained and can handle everything, but the downside is that you have to create Dto classes for every type of server-request which is time consuming and you have to synchronize the Dto type with your domain entity/business logic.
Depends on your definition of 'better' - whether this is means quicker to market, or an easier to maintain application in the long run.
Hand-crafting DTO's will mean the initial development effort will probably be longer than using a tool such as WCF Data Services. However, by exposing only DTO's your application will be more decoupled from the internal domain model than WCF Data Services, so future maintenance fixes will probably be easier and shorter.
I would tend towards DTO's if you have enough time and budget during initial development as money will be saved if the application lives for long enough, and it will be easier to fix/modify. Also using tools such as Automapper can alleviate many of the pain points associated with mapping between domain objects and DTOs.
An alternative would be to use a Persistent View Model that consists of the data that is in the form of your DTO(no mapping). Check out CQRS from Udi.