Consider the following case: you develop a class in which some members are accessed only from some other member functions (common). At some point, you decide to split you class into smaller chunks, dedicated to more specific tasks, withing the scope of the initial service. Will you relax your access control by changing the formerly private access into public? No. Friendship is the solution. This simple scenario should be enough to prove that no acccess control restrictions make sense in the absence of something like friendship: it is a plain non-sense to pretend that it "breaks encapsulation".
This scenario can be exemplified by the extraction of iterators from collections such as lists. This can be generalised to every situation where the access to a resource is inherently session-oriented (this should be extremely common, if not systematic, for reasons of seamlessness and generality: one cannot avoid that the access could need to be made session-oriented later in the development: this is just a more general, more powerful model of interaction).
Now, this priviledged relationship between a resource and sessions accessing it may naturally be described in abstraction, thus raising a need from some leverage through inheritance. Frienship makes this cumbersome in C++, which is a weakness.