The goal is to have more flexibility by being able to combine multiple providers.
In the past, switching between different providers could be very tricky, and require a rewriting of every application which relied on an old provider. Moreover, if you wanted to be able to query multiple providers, you had to implement that part in the application too.
With claims-based authorization, your application can simply say “I trust that provider”. It's then up to the provider to decide what to do with application requests: it can either process them directly, or delegate them to other providers. Thus, moving from one sub-provider to another or combining multiple ones involves changing the configuration of the provider, without affecting any of the applications—no code changes involved.
Company A had an historical database with employees' information, but a few months ago started migrating to a popular OpenID service. Meanwhile, it was bought by company B which also has an historical database and currently migrates to an OAuth service. Company A has around fifty internal applications, and company B has twenty of them. The goal is to ensure that all those applications work for the employees of both companies.
Without claims-based authorization, this task would probably involve modifying all seventy applications.
With claims-based authorization, all you have to do is to reconfigure the claims provider user by company A, and the one used by company B. The change will be transparent for the applications.
For more information on the subject, see A Guide to Claims based Identity and Access Control. It's far from being concise, but it's well written and explains very well the claims-based systems conceptually, instead of simply telling how to implement them technically in a software product.