Por que usar um int como chave primária de uma tabela de pesquisa?

A resposta à sua pergunta é lógica, não física - o valor que você procura pode mudar por motivos comerciais. Por exemplo, se você indexar seus clientes por endereço de e-mail, o que acontece quando um endereço de e-mail muda? Obviamente, isso não se aplica a todas as suas tabelas de pesquisa, mas os benefícios de fazer isso da mesma maneira em todo o aplicativo é que isso torna seu código mais simples. Se tudo é inteiro → relações inteiras internamente, você está coberto.

Apenas leia seu comentário para Sandy - talvez neste caso o que você realmente deseja seja um Check Constraint , não uma chave estrangeira/tabela de pesquisa, por exemplo:

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

Execute isso e você obterá:

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

Este é um método eficiente e de alto desempenho, mas a desvantagem é claro que adicionar um novo sabor significa uma mudança de código. Aconselho não fazer isso no aplicativo - porque você precisa fazer isso em todos os aplicativos que se conectam a esse banco de dados, esse é o design mais limpo possível porque há apenas um único caminho de código para fazer a validação.

“Usando o valor de pesquisa diretamente” – é um pouco contraditório com o objetivo real da tabela de pesquisa. Por que você está mantendo essa mesa? Se não for uma pesquisa.
Pode ser que eu tenha entendido mal a sua pergunta. Aqui está uma definição de tabela de pesquisa do msdn

Uma tabela de pesquisa é usada para exibir informações de uma tabela com base no valor de um campo de chave estrangeira em outra tabela. Por exemplo, considere uma tabela de Pedidos em um banco de dados de vendas. Cada registro na tabela Orders inclui um CustomerID indicando qual cliente fez o pedido. O CustomerID é uma chave estrangeira que aponta para um registro de cliente na tabela Clientes. Ao apresentar uma lista de Pedidos (da tabela Pedidos), você pode querer exibir o nome real do cliente, em oposição ao CustomerID. Como o nome do cliente está na tabela de clientes e você está apresentando dados da tabela Pedidos, é necessário criar uma tabela de pesquisa, que usa o valor CustomerID no registro Pedidos e usa esse valor para navegar no relacionamento e retornar o mais legível, nome do cliente.

Você pode detalhar o propósito da sua tabela de pesquisa? é usado para armazenar alguns dados estáticos como os seguintes e esses registros não são uma entrada de outros registros de tabelas?

tabela de sabores

Orange  
Pista  
Mango

Se a sua situação for acima, gostaria de recomendar não usar a tabela de pesquisa; provavelmente codifique esses valores de lista em seu aplicativo da web. Dessa forma, você pode evitar consultas desnecessárias ao banco de dados.

Como você qualificou sua pergunta com 'especificamente para uma tabela de pesquisa', a resposta provavelmente foi simplificada para 'economiza espaço'.

Acho que se você remover esse qualificador, sua pergunta será 'Por que usar chaves substitutas em vez de chaves naturais?' Escrevi o seguinte em apoio às chaves substitutas:

"Migrar um valor inteiro em vez de uma chave composta mais ampla tem vários benefícios. Ele fornece boa consistência em todo o modelo físico, em geral economiza mais espaço do que custa e reduz a E/S quando comparado à migração de chaves compostas; especialmente em um modelo normalizado. Além disso, eles simplificam a compreensão de um modelo e consultas de junções."

Em grande parte, é por isso que "se tornou a coisa padrão a se fazer". O subproduto infeliz é que as pessoas usam uma chave substituta e não pensam quais são as chaves candidatas ... Mas agora estamos saindo da sua pergunta :)

Uma das razões que sempre uso é que, se alguém digitou incorretamente um valor na tabela de pesquisa, digamos Oraneg em vez de Orange, é muito fácil alterar o valor na tabela de pesquisa.

A tabela de pesquisa com uma chave primária numérica exigirá apenas que o valor seja alterado na tabela de pesquisa.

A tabela de consulta usando os valores como chave primária precisará ser alterada na tabela de consulta e em todos os registros da tabela principal em que foi usada.

Ao definir o ID, você também pode garantir a exclusividade. Mas quando você toma, por exemplo, e-mail, como identificador único, você transfere a responsabilidade de exclusividade para um terceiro lado não confiável.