Identifiers that mean something will eventually be wrong

Every meaningful key encodes an assumption that changes.

Keys built from real-world attributes are appealing because they are readable and avoid a join. A code combining a region, a year and a sequence tells you something at a glance. It also encodes a set of assumptions: that the region will not be renamed, that an item belongs to one region, that the year is fixed, and that the sequence will not overflow.

All of those assumptions have failed somewhere. Regions merge, items move, records are backdated, and sequences designed for hundreds encounter thousands. When the assumption fails, the key either becomes wrong or has to change, and changing a key that is referenced by other tables, exported files and external systems is one of the more expensive operations available.

An arbitrary key has no meaning to lose. The readable code can still exist as an attribute, where it can change without structural consequence, which is the arrangement that survives.

The exception worth respecting is a genuinely external identifier issued and controlled by somebody else, where the whole point is to match their system. Even then it is usually better held as a unique attribute than as the primary key.

The other argument for arbitrary keys is operational rather than conceptual. Meaningful keys are frequently long, composite and used as foreign keys throughout, which inflates every index and every referencing table. That cost is invisible at small scale and becomes substantial at large.