As decided in symfony/Icu#12, symfony/icu is being deprecated in favor or a new symfony/intl-data component. This component will ship with the ICU/CLDR data, allowing the dependency on the intl extension and libicu to be removed.
The initial PR towards this is in #11884.

By default, the data is shipped in res files, which is a binary format for which we don't have a userspace parser yet. It should be determined whether to continue with the RES format, or use a different one like JSON.

https://github.com/commerceguys/intl can be seen as a proof of concept that uses YAML for the data. This turned out to be a mistake, since it takes approximately 0.1s to parse the en.yml currency file using symfony/yaml. In comparison, a PHP version is included in 0.00015s, and a JSON version is loaded and decoded in 0.00065s.
PHP has the advantage of "APC makes it faster", but the claimed memory can't be reclaimed, and I personally consider PHP to be a rather awkward solution for this use case.
Hence, my recommendation is to go with JSON.

There is no doubt that a userspace RES parser would be significantly slower than one that just calls json_decode(). There's also the complexity cost of including and maintaining the parser.

On the other hand, the RES format would certainly allow for filespace savings. However, I would argue that it is irrelevant, since the ICU data in JSON would be between 5 and 8 megabytes (as demonstrated by commerceguys/intl), thanks to locale deduplication (don't export currencies for "en-US" if "en" has the same data, rely on locale fallback), not exporting defaults, etc.
An additional 6mb would be irrelevant in today's world where people routinely upload documentation, tests and uncompressed resources to their production sites (all of which takes significantly more than 6mb).