I believe the primary (good) reason is:

Because people have learned from experience that not doing so leads to problems.

I've developed database applications for 20 years. Most critically I spent five years working with data warehouses. In the early days choosing another field seemed ok. Then we found duplicate records, sometimes unique validations were missing, sometimes (frequently) users had supplied different information that now needed to be merged, or whatever, and merging and managing records was a nightmare.

Even (or even particularly!) when the identifier 'seems' unique, this can turn out not to be true. For example: US Social Security Number. It should be unique to a person, right? Sure, but what if some records have been entered with SSN's that were mistyped by users in the past? Now there can be conflict issues with new, valid numbers that are entered for new records. A side note is that primary keys should also never be displayed as they lead to user assumptions about them and they are also not good for the best security model for web sites URL's.

So folks have learned:

Don't use a field that has 'any' business value or meaning as the primary key.
Use a surrogate key as surrogate keys are not derived from application data.

Because people have learned from experience that using such fields leads to problems.

I've developed database applications for 20 years. Most critically I spent five years working with data warehouses. In the early days choosing another field seemed ok. Then we found duplicate records, sometimes unique validations were missing, sometimes (frequently) users had supplied different information that now needed to be merged, or whatever, and merging and managing records was a nightmare.

Even (or even particularly!) when the identifier 'seems' unique, this can turn out not to be true. For example: US Social Security Number. It should be unique to a person, right? Sure, but what if some records have been entered with SSN's that were mistyped by users in the past? Now there can be conflict issues with new, valid numbers that are entered for new records. A side note is that primary keys should also never be displayed as they lead to user assumptions about them and they are also not good for the best security model for web sites URL's.
Always consider - will the user bookmark this URL and expect it to work in the future?

So folks have learned:

Don't use a "surrogate key" (e.g. SSN) as a primary key when the surrogate has 'any' business value or meaning.
Instead, use a primary key that is unique and not derived from application data.

I believe the primary (good) reason is:

Because people have learned from experience that not doing so leads to problems.

I've developed database applications for 20 years. Most critically I spent five years working with data warehouses. In the early days choosing another field seemed ok. Then we found duplicate records, sometimes unique validations were missing, sometimes (frequently) users had supplied different information that now needed to be merged, or whatever, and merging and managing records was a nightmare.

Even (or even particularly!) when the identifier 'seems' unique, this can turn out not to be true. For example: US Social Security Number. It should be unique to a person, right? Sure, but what if some records have been entered with SSN's that were mistyped by users in the past? Now there can be conflict issues with new, valid numbers that are entered for new records. A side note is that priary keys should also never be displayed as they lead to user assumptions about them and they are also not good for the best security model for web sites URL's.

So folks have learned:

Don't use a field that has 'any' business value or meaning as the primary key.

I believe the primary (good) reason is:

Because people have learned from experience that not doing so leads to problems.

I've developed database applications for 20 years. Most critically I spent five years working with data warehouses. In the early days choosing another field seemed ok. Then we found duplicate records, sometimes unique validations were missing, sometimes (frequently) users had supplied different information that now needed to be merged, or whatever, and merging and managing records was a nightmare.

Even (or even particularly!) when the identifier 'seems' unique, this can turn out not to be true. For example: US Social Security Number. It should be unique to a person, right? Sure, but what if some records have been entered with SSN's that were mistyped by users in the past? Now there can be conflict issues with new, valid numbers that are entered for new records. A side note is that primary keys should also never be displayed as they lead to user assumptions about them and they are also not good for the best security model for web sites URL's.

So folks have learned:

Don't use a field that has 'any' business value or meaning as the primary key.
Use a surrogate key as surrogate keys are not derived from application data.