Como prefácio, observe que uma Chave Primária não precisa ser uma única coluna:ela pode ser composta por várias colunas:isso é conhecido como Chave Composta. Observe também que nem toda tabela tem um AUTO_INCREMENT /IDENTITY coluna, e você pode ter um UNIQUE restrição em uma única coluna dentro de uma chave composta de qualquer maneira.

1. 
   Não existe - mas não faz sentido para um DBMS proibir essa redundância porque você precisaria de lógica e complexidade adicionais para lidar com essa condição, enquanto não há nenhum dano real causado por ter ambos (além do impacto no desempenho de ter que manter dois índices).
   
2. 
   Como dito acima:porque o custo de oportunidade de detectar e prevenir essa redundância não vale a pena.
   

Outra coisa a considerar é que a definição de chave primária de uma tabela não é imutável e, portanto, está sujeita a alterações. Uma tabela pode já ter colunas com um UNIQUE configuração de restrição e, em seguida, o projetista do banco de dados decide incluir isso em uma nova definição da chave primária - seria pouco amigável exigir que a restrição antiga fosse removida primeiro, especialmente se outras partes de seu sistema de aplicativo dependerem de essa restrição UNIQUE estar lá (por exemplo, um 1:0..1 definição de relacionamento).

(Além disso, AUTO_INCREMENT não é mutuamente inclusivo com UNIQUE ou PRIMARY KEY :você pode usar AUTO_INCREMENT com colunas não exclusivas (por exemplo, se AUTO_INCREMENT é adicionado depois que uma tabela já contém dados) e, ao contrário, uma PRIMARY KEY pode usar valores únicos provenientes de outro lugar, como outra coluna de identidade como chave estrangeira (chaves primárias compostas podem conter chaves estrangeiras!) você deve nunca fazer isso na realidade)).