@Lars Kemmann: I might agree about the data portal if it were only a facade, but that's not the case.
The primary purpose of the data portal is to abstract the entire concept of an "application server", thereby providing location transparency. When you call the data portal your code doesn't know if the app is deployed in a 1-, 2-, 3-, or 4-tier environment, and it doesn't need to know or care.
Additionally, the data portal automatically manages a number of common requirements such as impersonation of custom principal/identities from the client, flow of client culture onto the server thread, abstraction of network technologies (Remoting, asmx, WCF, Web API, raw TCP, etc).
It is true that the data portal could have been interface-based. I conciously chose not to go that route because I wanted to support method overloading, thus allowing you to have different read (fetch) method overloads to support different application scenarios.
That said, the current CSLA 4.3 data portal does provide a number of important interfaces necessary for mocking and unit testing scenarios, including at the data portal level. If your primary concern was around mocking and testing you might find that the concern no longer applies in current versions of the framework.