Typically, when building integrations to a system, you can key off an ID (typically an integer) that is associated with a displayed value.
When the ID is separate from the Display Value, this allows for the Display Value to be changed over and over, following the needs of a business unit, marketing team, usability consultant, etc.
The Display value can change and the behind-the-scenes integrations (both pushing data into the system and pulling data out of the system) never have to change, thereby seperating IT function from the business.
Unfortunately, Salesforce does not easily accomidate this standard and Picklist values are stored as text, both in the record itself as well underlying meta data. When building integrations, you have to key off the string and not the ID. Therefore, every time a business unit, marketing team, usability consultant or whoever decides the value in a picklist should be changed, ALL integrations that interact with that field need to be changed. If there is an upstream integration, where another system is pushing that data into Salesforce, that integration has to push the new string value. If there is a downstream integration that relies on data coming from Salesforce, that integration needs to handle the new string value.
Instead of being able to respond quickly to a change requested by a business unit, marketing team, usability consultant or whoever, that change requires significant involvement from IT.
This idea would be to expand the current functionality of the Picklist to include an associated internal ID.