I think the success of Doctrine 2 speaks for itself. In practice the speed/memory issues are not bad especially when compared to the alternatives.
Consider writing an application in which a single request requires 10 objects each with 10 properties. Make sure the app actually does something besides querying the database. That might give you a more useful basis for comparison.
From a slightly different point of view, I’m not convinced that methods like Message::compose($title, $content) really implement business logic. I suspect they just store the arguments internally which would make them crud. If they actually do something else then fine.
The point being is that if you have an anemic domain model then you may as well just use public properties or even arrays to max out performance.
Finally, if you have not already, take a look at the Command Query Responsibility Segregation (CQRS) pattern. http://www.whitewashing.de/2012/08/18/oop_business_applications__command_query_responsibility_seggregation.html. I think it’s safe to say that most requests are read only and that the requirements for read only data can be drastically different than the requirements for read write. Note that the writer of the post I linked is one of the primary developers of Doctrine 2. Lots of good stuff on his site.