Parece que você tem um plano ideal para executar a consulta. Vai ser difícil melhorar isso. Aqui estão algumas observações.

A consulta está fazendo um Clustered Index Scan no índice PK_States. Não está usando o índice espacial. Isso ocorre porque o otimizador de consulta acha que será melhor usar o índice clusterizado em vez de qualquer outro índice. Por quê? Provavelmente porque há poucas linhas na tabela Estados (50 mais talvez algumas outras para Washington, D.C., Porto Rico, etc.).

O SQL Server armazena e recupera dados em páginas de 8 KB. O tamanho da linha (consulte Estimar tamanho da linha) para a operação de filtro é de 8.052 bytes, o que significa que há uma linha por página e cerca de 50 páginas em toda a tabela. O plano de consulta estima que processará cerca de 18 dessas linhas (consulte Número estimado de linhas). Este não é um número significativo de linhas a serem processadas. Minha explicação não aborda páginas extras que fazem parte da tabela, mas o ponto é que o número é em torno de 50 e não 50.000 páginas.

Então, de volta ao porque ele usa o índice PK_States em vez do índice SPATIAL_States_Boundry. O índice clusterizado, por definição, contém os dados reais da tabela. Um índice não clusterizado aponta para a página em que os dados existem, portanto, há mais páginas a serem recuperadas. Assim, o índice não clusterizado torna-se útil apenas quando há grandes quantidades de dados.

Pode haver coisas que você pode fazer para reduzir o número de processos de páginas (por exemplo, usar um índice de cobertura), mas sua consulta atual já está bem otimizada e você não verá muita melhoria de desempenho.