This issue discusses the new intl API that's being made in #9206.
I've opened it because I believe this discussion is outside the scope of that PR (and would probably have a very different target version).
The current code also has the same approach (API with static methods).

The ICU data ships with definitions for currencies, countries, languages and more.
However, since the API imitates ICU itself, it feels odd and less PHP-like.
Instead of returning objects with the relevant information, the central service has a static method per relevant property that returns an array.

Here's a currency example:

$currencyCode = 'EUR';
$numericCode = Currency::getNumericCode($currencyCode):
$fractionDigits = Currency::getFractionDigits()
$name = Currency::getName($currencyCode);
$symbol = Currency::getSymbol($currencyCode);

Now let's compare that to how commerceguys/intl does it:

$repository = new CurrencyRepository();
// Get the USD currency using the default locale (en).
$currency = $repository->get('USD');
echo $currency->getCurrencyCode();
echo $currency->getNumericCode();
echo $currency->getFractionDigits();
echo $currency->getName();
echo $currency->getSymbol();

In the second example we get an object implementing the CurrencyInterface.
This is important because in most ecommerce scenarios there is a need for the admin to modify existing currencies or define custom new ones, which leads to currencies being stored in the database. So, a Doctrine entity can implement the CurrencyInterface and behave just as the currency created from default definitions, as far as the rest of the system is concerned.

webmozart said:

It does not represent individual I18N objects (currencies, locales etc.) as objects - for performance > reasons. For example, if you need a list of locale names, initializing an array of hundreds of Locale > objects first adds noticeable overhead.

I'm not convinced because we already have the cost of all those arrays storing the names, symbols, fraction digits, etc. Arrays have been shown to be very expensive.
Having an array of typed objects instead provides a much cleaner API that can integrate nicely with other components and systems. If there's a performance impact, it's well worth it, but I'm prepared to do benchmarks.