Você diz que o CAMPO47 é altamente seletivo. Mas você está apenas filtrando IS NOT NULL. Portanto, não importa quantos valores distintos ele tenha, o otimizador não o usará como ponto de entrada.
E quão seletivo é? Como você pode ver nas cardinalidades no plano de explicação, selecionar STATO='SC' encontra 12.856 linhas em sua tabela. 12702 dessas linhas obviamente têm CAMPO47 com um valor, portanto, apenas 154 linhas são filtradas pelo teste de nulidade. Se o otimizador tivesse aumentado o índice em CAMPO47, quantas linhas isso teria retornado? Provavelmente muito mais.
O otimizador pode usar apenas um índice de heap para acessar linhas em uma tabela. (O mecanismo é diferente para índices de bitmap quando eles estão aplicando uma transformação em estrela). Então, se você acha que os acessos adicionais à tabela são um fardo insuportável, então você tem uma opção:um índice composto. Se STATO for realmente não seletivo (relativamente poucas linhas), você provavelmente estará seguro em substituir o índice existente por um em (STATO, CAMPO47).
Existe um velho truque para forçar o banco de dados a usar um índice para acessar operações IS NOT NULL, que é usar um operando que só pode ser verdadeiro onde a coluna contém um valor. Por exemplo, algo assim para colunas de string (suponho que algo chamado CAMPO47 seja apenas uma string):
AND campo47 >= chr(0)
Isso corresponderá a qualquer coluna que contenha um ou mais caracteres ASCII. Não tenho certeza se isso levará à otimização de "dois índices" que você descreve, mas vale a pena tentar. (Eu testaria isso sozinho, mas não tenho acesso a um banco de dados Oracle no momento, e o SQL Fiddle disparou quando tentei ver o Plano de Explicação)
