The paper Carlos mentions is quite good. Also, I helped write an ODCA document on Cloud Brokering (a link is below), which deals with many of the issues that federation tries to solve. Some of the tasks described that cloud brokering deals with (page 8):
Simplifying the service acquisition process
Aggregating disparate cloud services into a "single" service from the cloud broker
Integrating public and private cloud services (hybrid cloud)
Centralizing governance of the cloud service(s)
Technical Report Open Data Center Alliance Usage Model: Cloud Service Brokeri...
In Manufacturing, risk management of the supply chain is key. The golden rule never to have any component in your system be single-sourced is a time honored system design concept. For some reason, in IT, this same risk management sensibility is lacking, and many organizations are quite ok to put all their eggs in one basket. Cloud Federation is the messaging to NOT single source your cloud service.
For those organizations that are deeper in the cloud maturity progression, the cloud is a process to deliver more agile service, not AWS or Azure. When you are designing these 'cloud' processes, you quickly realize that different workload have vastly different characteristics and thus need different infrastructure. Cloud Federation is also a mechanism to organize these different requirements. This is particularly important for organizations that interface with networks that don't involve human beings, for example, industrial embedded and the IoT. High performance computing is another domain where federation is applicable to optimize security and ROI.
Another aspect could be creating a large scale cloud infrastructure for acquiring big data. If some small companies are not big enough to generate useful data from their infrastructure, they can form a federated cloud for data collection. An example for this kind of project would be a federated cloud of universities that share data about their IT research projects.