Well, if a domain class has 50 attributes, and there are use cases that consistently concern only a certain subset of them, the first thing I would look at is, why, the class itself. Chances are, even from the domain modeling perspective, it should be broken down to some finer pieces.
Take a typical use case - returning search results which can then be used to drill down to view details. My service layer provides two methods for handling this: one to take search criteria and return summary info about the records, another that takes the id of a specific record and returns all the info about that record.
Let's say the records have 20 attributes, only 3 of which are necessary to summarize the record, and you don't want to use DTOs. You could return the full data set for each record, but in a distributed architecture with high traffic that won't scale very well. You could use the domain objects and only populate certain fields, but that just seems wrong. You could use a generic container to hold the data such as arrays of strings or hashmaps, but as you said you lose the benefits of explicit datatypes. You could send the data back as XML with a schema, but someone will still need to dump that data into an object.
And what about the use cases where your search results need to display data from two different objects? Would you design your domain objects to meet that requirement, even if logically the attributes should be in two different classes? This is why like it or not the layer the UI interacts with does need to take the UI into account.
I generally start my designs with the academic "right way" to do things, then I bend my principles as necessary to get the best end result in terms of maintenance, performance, etc. I don't like DTOs because of the extra work involved in copying data between them and domain objects, but there are times (such as returning search results) when I think it is the right approach.