@Matt Sheppard:
Digamos que você tenha uma mesa de clientes. Certamente você não deseja que um cliente exista na tabela mais de uma vez, ou muita confusão acontecerá nos departamentos de vendas e logística (especialmente se as várias linhas do cliente contiverem informações diferentes).
Portanto, você tem um identificador de cliente que o identifica exclusivamente e garante que o identificador seja conhecido pelo cliente (em faturas), para que o cliente e o pessoal do serviço de atendimento ao cliente tenham uma referência comum caso precisem se comunicar. Para garantir nenhum registro duplicado do cliente, adicione uma restrição de exclusividade à tabela, por meio de uma chave primária no identificador do cliente ou por meio de uma restrição NOT NULL + UNIQUE na coluna identificador do cliente.
Em seguida, por algum motivo (no qual não consigo pensar), você será solicitado a adicionar uma coluna GUID à tabela do cliente e tornar essa a chave primária. Se a coluna de identificação do cliente agora não tiver garantia de exclusividade, você estará solicitando problemas futuros em toda a organização porque os GUIDs sempre serão exclusivos.
Alguns "arquitetos" podem dizer que "ah, mas lidamos com a restrição real de exclusividade do cliente em nosso nível de aplicativo!". Certo. A moda com relação a essas linguagens de programação de uso geral e (especialmente) às estruturas da camada intermediária muda o tempo todo e, geralmente, nunca supera o seu banco de dados. E há uma chance muito boa de que você, em algum momento, precise acessar o banco de dados sem passar pelo aplicativo atual. == Problema. (Mas, felizmente, você e o "arquiteto" se foram há muito tempo, portanto você não estará lá para limpar a bagunça.) Em outras palavras: mantenha restrições óbvias no banco de dados (e em outras camadas também, se você tiver A Hora).
Em outras palavras: pode haver boas razões para adicionar colunas GUID às tabelas, mas não caia na tentação de diminuir as suas ambições de consistência nas informações reais (== não GUID).