Some alias relations are vastly different than others. The distinction between Asia/Calcutta and Asia/Kolkata does not matter for the purposes of localized names; they really identify the same place. So we need to map them together for the purpose of getting localized names.
However, the difference between Asia/Tokyo and Asia/Seoul (even if they had the same rules) is very important to end users, and must be maintained. For localization, we are lucky in a way that the rules are sufficiently different that for the most part cities in one country are not aliased to those in another. That is of course not an accident; timezone rules are determined by territory governments, so it is quite likely that at some point in time they'll disagree.
In CLDR we have to have stable canonical IDs for the purposes of localization, ones that distinguish by country; we originally based them on zone.tab, but had to deviate from that because it is unstable. So what we use to canonicalize is in the following:
That continues to distinguish by country, even where items are aliased in the TZDB.
<type name="zwhre" description="Harare, Zimbabwe" alias="Africa/Harare"/>
<type name="mzmpm" description="Maputo, Mozambique" alias="Africa/Maputo"/>
Where there are multiple aliases, the first is the canonical one:
<type name="inccu" description="Kolkata, India" alias="Asia/Calcutta Asia/Kolkata"/>
So you'll see translations for those canonical IDs like:
<zone type="Asia/Calcutta">
<exemplarCity>Калькутта</exemplarCity>
</zone>
So if some system needs stable identifiers, it may be possible for it to use the CLDR identifiers. The use of those is, however, predicated on using an underlying TZDB for the calculation of times associated with those identifiers.
I agree if we had had just arbitrary IDs, there would have been less of a reason to have zone.tab be unstable, because people wouldn't have felt the need to have destabilizing changes simply for spelling changes, etc. On the other hand, items like Asia/Calcutta really should have always been treated simply as internal IDs, never shown directly to end users. So there should have been no need to have destabilizing changes just for spelling, etc. And there is advantage for programmers debugging code to be able to see something like Asia/Calcutta instead of some incomprehensible ID like TZ597.
On the other hand, in CLDR we did actually need to have short alphanumeric IDs for use in restricted environments like BCP47, so you see the name=... values above. Those are based on the UN/LOCODE ids, which are vaguely mnemonic: but we had to add extensions for cases where those codes are deficient, and impose a stability rule on our usage, because UN/LOCODE ids are also not guaranteed to be stable—and are far less well maintained than the TZDB. (I don't at all want to seem like I'm slamming the TZDB: the work done for so many years by the TZ maintainers has has been a true service to the world as a whole!)