Benefício ou caso de uso para nomes de variáveis/parâmetros/tabelas temporárias/procedimentos temporários vazios?

Acabei de descobrir,por puro brilhoacidentalmente, esse SQL Server permite que você crie variáveis, parâmetros, variáveis ​​de tabela, tabelas temporárias (locais e globais) e stored procedures temporárias (locais e globais) sem nenhum nome! Bem, pelo menos não no que eu consideraria ser um nome. Ou seja, você pode especificar DECLARE @ INT = 5;e isso é T-SQL válido: ele executa sem erro e nem mesmo é sinalizado com um sublinhado vermelho rabiscado no SSMS (código com lista completa de exemplos mostrados no final desta pergunta).

Dado que a página do MSDN para identificadores de banco de dados declara (ênfase minha):

Existem duas classes de identificadores:
Identificadores regulares
...
Identificadores delimitados ... Os identificadores
regulares e delimitados devem conter de 1 a 128 caracteres. Para tabelas temporárias locais, o identificador pode ter no máximo 116 caracteres.

e isso certamente não parece ser o comportamento pretendido, inicialmente considerei isso um defeito (não causa nenhum erro, mas não parece ser o comportamento "correto") e registrei um bug do Connect: Parâmetro, Variável e Temporário Nomes/identificadores de tabelas e procedimentos podem estar vazios .

NO ENTANTO, essa mesma página do MSDN também afirma:

Regras para identificadores regulares

Os nomes de variáveis, funções e procedimentos armazenados devem obedecer às seguintes regras para identificadores Transact-SQL.

1. O primeiro caractere deve ser um dos seguintes:

   • Uma letra conforme definido pelo Padrão Unicode 3.2. A definição de letras Unicode inclui caracteres latinos de a a z, de A a Z e também caracteres de letras de outros idiomas.

   • O sublinhado (_), arroba (@) ou sinal de número (#).

     Certos símbolos no início de um identificador têm um significado especial no SQL Server. Um identificador regular que começa com o sinal de arroba sempre denota uma variável ou parâmetro local e não pode ser usado como nome de nenhum outro tipo de objeto. Um identificador que começa com um sinal numérico denota uma tabela ou procedimento temporário. Um identificador que começa com sinais numéricos duplos (##) denota um objeto temporário global. Embora o sinal de número ou o sinal de número duplo possam ser usados ​​para iniciar os nomes de outros tipos de objetos, não recomendamos essa prática.

Portanto, pode-se interpretar que o requisito mínimo de 1 caractere para o nome (da parte superior citada mostrando "1 a 128 caracteres") seria satisfeito simplesmente tendo um @ou #desde:

1. afirma que esses seriam o "primeiro" caractere em vez de algum tipo de indicação externa do tipo de coisa que é, e
2. não há nada afirmando que, quando um @ou #é o primeiro caractere, são necessários de 2 a 128 caracteres.

ENTÃO, se esse comportamento não é um bug nem um defeito, há algum benefício em usar essa habilidade? Existe um caso de uso legítimo que é beneficiado por ser capaz de fazer isso (ou seja, algum benefício funcional para um projeto e não apenas reduzir a contagem de caracteres do código-fonte)?

Não consigo pensar em um, além de ser pouco profissional e deixar um código terrivelmente incontrolável para todos quando você muda para um novo empregador.

Mas também posso ver um problema funcional relacionado, pois existem vários blocos de código em muitos projetos que analisam objetos T-SQL. Se alguém usar um padrão RegEx procurando @seguido por algo como (\w+), ele ignorará essas entradas.

-- Local variables:
DECLARE @ INT = 99;
DECLARE @@ VARCHAR(10);
SELECT CONVERT(VARCHAR(20), @), STR(@);
SET @@ = STR(@);
SELECT @@;
GO

-- Table Variable:
DECLARE @ TABLE (Col1 INT);
INSERT INTO @ (Col1) VALUES (86);
SELECT * FROM @;
GO

-- Local Temporary Table:
CREATE TABLE # (Col2 DATETIME);
INSERT INTO # (Col2) VALUES (GETDATE());
SELECT * FROM #;
SELECT OBJECT_ID(N'tempdb..#');
GO

-- Global Temporary Stored Procedure
CREATE PROCEDURE ##  ( @ INT = 999 )
AS
SELECT @ AS [Huh?];
GO

EXEC ##;

EXEC ## 204;

DECLARE @ INT = 12345;
EXEC ## @ = @;
-- The above also work in another session on the same instance, in a different Database

SELECT * FROM tempdb.sys.parameters tsp WHERE tsp.[object_id] = OBJECT_ID(N'tempdb..##');
-- returns 1 row showing a name of just "@"

PS Pesquisei aqui, nos Googles e no Microsoft Connect e não consegui encontrar nenhuma referência a nomes de variáveis ​​"ausentes" ou "vazios" ou "identificadores". No entanto, @MartinSmith apontou essa "habilidade" sendo usada na seguinte resposta do StackOverflow para reduzir a contagem de caracteres do código: Crie um gráfico ASCII das palavras mais usadas em um determinado texto .