A relational database would typically contain several related tables.
The relationships between tables use what is called a foreign key column which is basically the primary key of a parent table placed in a child table's list of columns (with other rules not listed here). For simplicity, you can say that relationships in a database depend on Primary keys very very much. Now if a value is changed, the system has to perform so many changes to coupe with this change. As an example, say you have a Social Security Number of a person and you keep track about this person's properties, cars, jobs, wive(s), kids and let's say you change the SSN value. The system will have to change the corresponding value in each of those related (child) tables.
This process is not always good to perform on-line.
Another reason is business related. Say you are issuing an EmployeeID Cards,
if the number on the card changes, then the card is no longer usable and you have to print another one, not only that, but this means that the salary information has to change, the insurance information has to change as well as other information related to the EmployeeID. In business, sometimes not all this information is integrated or even automated, so this change leads to a lot of work and possible inconsistency of information in manual systems.
Such changes may not only be localized to one organization and may have to affect other external organizations or systems, which would make life very difficult, because you have to ask your business partners to carry such changes on their end too.
Yet, another reason for not changing key values is that when you do so, history tracking becomes difficult. All history logs and documents will not reflect the current value making it difficult to interpret or even find data in manual systems.