Q:

Capturar NullPointerException é má prática?

Tenho estado meio encucado com questões de segurança e vulnerabilidades ultimamente, e, em minhas pesquisas, cheguei em um artigo que me intrigou.
Segundo a OWASP:

Description
It is generally a bad practice to catch
NullPointerException.
Programmers typically catch NullPointerException under three
circumstances:
1 - The program contains a null pointer dereference. Catching the
resulting exception was easier than fixing the underlying problem.
2 - The
program explicitly throws a NullPointerException to signal an error
condition.
3 -The code is part of a test harness that supplies unexpected
input to the classes under test. Of these three circumstances, only
the last is acceptable.

Ou seja, segundo esse texto, a única situação aceitável para capturar NullPointerException é em casos de teste, aonde o input pode ser algo inesperado.
Por que não é uma boa ideia capturar NullPointerException?
Visto que não é uma boa ideia, como devo proceder caso essa exceção seja algo plausível dentro de um escopo?
Como NullPointerException pode ser uma ameaça para meu sistema?

A:

De uma maneira geral é sim. Isto normalmente ocorre por um erro de programação. Se há a expectativa de que uma informação possa ser nula, teste antes de acessá-la. Esta é a única prática aceitável em quase todas situações. Eu diria em todas dentro da normalidade, mas estou sendo precavido porque pode ter alguma situação útil. As exceções ficam por conta de testes ou resolver um problema de algo de terceiro que você use e lança a exceção equivocadamente. Pra mim isso nem é aceitável, se algo é tão ruim, ou conserte ou troque de fornecedor porque isso é grave.
Acha que é plausível? Tem que demonstrar porque é. Provavelmente é um erro de avaliação.
Se há este problema de programação há alguma coisa que está errada no código, ou o programador não tem noção do que está fazendo. Isto por si só já é um perigo. Eu não vejo um problema de segurança direto, mas talvez classifiquem assim pelo efeito indireto. Por exemplo, se a aplicação quebra pode ser que ela tenha sido mal feita em outro ponto e deixe alguma coisa em aberto que crie a vulnerabilidade. O problema não é da NPE e sim dela permitir que outra falha aconteça.
Por outro lado uma exceção geral em algum ponto de saída da aplicação deve capturar todas exceções, mesmo as de programação para tratar a saída padrão, já que ela expõe dados internos da aplicação que podem ser usados para explorar alguma vulnerabilidade. Note que isso não é tratar a NPE e sim tratar o que não pode ser tratado, só "maquiado". Idealmente não deveria ocorrer erros de programação em produção.
De qualquer forma, assim como boas práticas são ruins, más práticas também. Quem diz que algo é ruim deve dizer porque, caso contrário se você não consegue determinar por conta própria ou outra fonte, desconsidere a afirmação. Neste caso até que descubra o porquê, não trate como um problema de segurança e sim de programação apenas.
if (objeto != null) {
    //faz o que tem que fazer
}

Se pode, e deve fazer isso antes de ter a exceção, por que vai deixar acontecer para tratá-la? Não faz sentido.
Algumas perguntas úteis:

Exceções consomem muito processamento. Verdade ou lenda?
Boas práticas com tratamento de exceção Java
Exceções devem ser usadas para controle de fluxo?

