Como não há unsigned int no SQL Server, uma semente de identidade de -2.147.483.648 não faz mais sentido para tabelas grandes?

Não há nada de errado em começar em -2.147.483.648 no que diz respeito ao SQL Server. Começar em 2.147.483.647 e contar de trás para frente IDENTITY(2147483647,-1)também é perfeitamente válido.

Coisas que me fariam desconfiar de fazê-lo:

1. Pode confundir as pessoas que não esperam ver valores negativos em tais posições. É incomum o suficiente para que possa facilmente parecer um bug. Se nada mais você pode ficar cansado de explicar isso.
2. Se você passar os IDs para outros serviços por qualquer motivo, eles podem falhar na validação de entrada para esse código sem esperar ver negativos (um sistema externo não deve se preocupar com seus IDs internos assim, mas há muitas coisas que acontecem que devem não!). Além disso, o código em outras camadas do seu aplicativo pode usar um int32 não assinado, tornando a opção "down from int.max" ainda mais perigosa, pois você não atingirá o problema até cair abaixo de 0.
3. As pessoas às vezes usam números mágicos negativos para ter um significado especial, e isso pode causar colisões que levam a erros difíceis de explicar. Por exemplo, encurtar WHERE (x.a<>y.a OR x.a IS NULL AND y.a IS NOT NULL OR x.a IS NOT NULL AND y.a IS NULL)para WHERE ISNULL(x.a,-1)<>ISNULL(x.a,-2)é algo que já vi várias vezes. Não é provável para o seu PK, pois isso nunca será, NULLmas pode acontecer na comparação de valores de FK em outras tabelas. Eu até vi alguém usar somevalue>-1no lugar de somevalue IS NOT NULL(aparentemente há uma circunstância em que isso é mais eficiente, embora ele nunca tenha explicado para minha satisfação qual poderia ser a circunstância!). Pode haver isso e outras travessuras estranhas no código fora do banco de dados também.
4. Mais importante: escala , escala particularmente inesperada. Software e dados que não morrem cedo geralmente sobrevivem à visão de seus criadores e crescem mais ao longo do tempo de acordo. A menos que você esteja muito limitado por armazenamento ou RAM (talvez em um sistema embutido), planeje pelo menos uma ordem de magnitude maior do que o esperado.
   Se eu espero que atingir ~ 400.000.000 seja provável no tempo de vida dos dados, muito antes da diferença entre 2 ou 4.000.000.000 ser considerada, já vou optar por uma chave maior, então dobrando usando valores negativos não vai fazer muita diferença.
   Você não quer fazer uma mudança em algo básico como um PK em quatro anos, mas menos ainda em oito anos. Em ambos os casos, se o design dura tanto tempo, você esqueceu os detalhes e muitos outros bits & bobs começaram a depender da chave, de modo que as mudanças que precisam ser feitas crescem massivamente, e mesmo essa única mesa será um trabalho enorme para change (a menos que a maioria dos dados seja excluída após um tempo), pois contém muitas linhas, então você tem todas aquelas que se referem a ele com FKs para trabalhar também.

Não, você não está perdendo nada. As identidades devem ser apenas substitutos internos sem sentido, que são para o computador alocar e lidar, e o computador não se importa se você usa números positivos ou negativos.

No entanto .. nunca é tão simples. Sempre haverá um humano em algum lugar tentando ler essas coisas, compreendê-las e reconciliá-las. Apenas achamos mais difícil pensar em números negativos maciços do que em números positivos maciços. Não torne mais difícil para as pessoas que tentam fazer seu sistema funcionar. Eventualmente, eles vazarão - em relatórios, referências externas, telas. Tente dizer ao cliente menos dois bilhões que eles precisam usar um teclado de telefone para inserir seu ID de cliente para acessar sua conta!

Se você acha que há alguma chance de transbordar a identidade em um futuro provável, use o tipo de dados maior imediatamente. As considerações que levaram aos problemas do Y2K são passadas. O disco é barato. A memória extra usada por consulta pode ser equilibrada com a tranquilidade de saber que o aplicativo foi projetado para uma vida útil de 50 anos. Você não precisará implementar monitoramento extra no dia 4 (ou 8!) anos a partir de agora, quando o último inteiro for alocado.

Conheço um sistema que estourou e as identidades foram decrementadas em 2,1 bilhões, efetivamente reiniciando em int.Min. Eu vi outro uso de identidades negativas, mas falha porque o log as converte em varchar(10) truncando o sinal de menos. Conheço outro onde a identidade foi definida como numeric(18,0), só para ter certeza. E eu vi outro estouro sem um plano em vigor, derrubando o sistema por algum tempo. Porque quando você alcança int.max, você tem, por definição, quatro bilhões de linhas para lidar, e isso não é um fim de semana divertido.