Como agregado a lo que ya te comentó Hemlish2000, cuando cursas la asignatura en la Universidad no sólo te dan esa explicación (la PK no necesariamente es numérica, ni autoincremental), sino que además se aclara que determinar las claves candidatas (CC) de una tabla son una parte importante del proceso de normalización, y sólo es justificable usar claves numéricas (autoincrementales o no), si llegados a la 3FN aún no se ha encontrado una CC.
Además, hay un problema adicional y es que el uso de PK numericas incrementales en bases de datos produce serios problemas en el caso de necesitar integrar y consolidar datos, por cuanto datos provenientes de diferentes bases o diferentes servidores pueden usar la misma PK para diferentes datos de tablas iguales. Imagina un sistema de clientes distribuido en diferentes bases y sucursales., que no esté completamente integrado...
Obviamente hay soluciones para eso, pero no son ni por asomo tan prácticas como buscar un ID con atributos propios de la tabla tales que en todo el universo posible de instancias no se pueda repetir.
Los números de documentos son prácticos, dependiendo de qué documentos y cómo se gestionan, pero eso depende de cada país.
Lo que sí puedo asegurarte es que el uso de ID autoincrementales es un vicio de los programadores, y no de los arquitectos de datos. Son fáciles de usar, fáciles de programar, y parecen eficientes. Pero a la larga son problemáticos.
Si el tipo te dijo que una PK debe ser numerica y autoincremental, yo diría dos cosas: 1) Es un programador, 2) no ha leído nunca los trabajos de
T.J. Teory, D. Yang, J.P. Fry del modelo entidad-relacion, ni tampoco los Fundamentos de Bases de Datos de
H. F. Korth y A. Silberschatz, sobre los que se basa nel desarrollo de las bases de datos relacionales.