Cristoph,
first of all, thank you for your comments: they are a great value!
In general, consider that SQLBI approach is long-term oriented. The need for an higher number of levels in the architecture (and for a way to decouple them as much as we can) borns from our real-world experience. The complexity of relationships in real-world data sometimes does require complex relational models, with a lot of relationships between entities, most of them optionals and not mandatory. Trying to put these relationships in a "flat" star schema often requires a simplification and possibly the loss of some information, just because the user don't need them at that particular point in time. However, we don't want to lose precious data for future analysis (and future requirements!) and we also don't want to force a dimensional model to be too much complex, including data for future requirements. Too much complex models are not used at all, in our experience.
For these reasons, we say that a "single poin of truth" can be better expressed using a relational model than a dimensional one. You have to think in a long-term perspective, anyway.
Data Mart for Departments or Processes - sincerily, with SQLBI we create Data Mart when they are needed, following the requirements that can be different each time. I think there is not so much importance here in discussing where the Data Marts have to come from. Oftentimes, we had to build completely different data marts using the same source data just because of the different representation of data required by end users. In that specific case, we don't want to spend time discussing if the difference were about departments (they were different) or processes (they could be considered different, but in reality we were analyzing exactly the same data, but from two differents points of view - could we say they were part of different processes?).
Finally, yes, the knowledge of customers processes is a key factor for the success of a BI solution (or of "any" solution!) and we can't simply define our Data Warehouse looking only at the OLTP data sources. In general, you always have to find the right balance. The point we wanted to highlight is that you cannot define your Data Warehouse model basing only on user requirements of the final reports they want to build. At the same time, you cannot design that model basing only on existing structures of source data. You need the knowledge of both and, of course, the knowledge of processes that makes that data meaningful!
I really appreciate this kind of discussions. Thanks again for your feedback.
Marco