Você achou a solução e agora quer arrumar um problema para usar a solução. É mais ou menos o que fazem as pessoas que descobrem os design petterns do GOF.
Quando não acha como usar em um lugar tem grande chance de não ter uso ali.
No seu exemplo, não é fácil achar algo estático para uma Pessoa. É possível, mas tem grande chance de ser um design errado e que deveria estar em outra classe.
Aí caímos em outro problema dos exemplos artificiais. Eles podem ajudar em algo específico, mas no fim ensina errado o geral. Por exemplo, o tal do Cachorro e Gato que herdam de Animal mostra muito bem como é a herança e ensina errado como usar.
Com requisitos reais, tem o problema, bem descrito, e aí vamos achando soluções para ele, e podemos aplicar algum mecanismo adequado para aquele caso, quem sabe algo estático.
Se sabe que os membros estáticos pertencem à classe e não aos objetos, devem entender que serão dados globais, que só existe um por toda a aplicação. Sua classe precisa disto?
Cuidado, estado global pode ser um enorme problema, a menos que seja imutável. Veja mais em https://pt.stackoverflow.com/q/21158/101.
Uma boa estratégia para começar a ter uma ideia onde faz sentido ter algo assim é começar a olhar a documentação das bibliotecas padrões do Java. Verá que a maioria das classes não possuem nada estático, em especial campos estáticos, ou até mesmo getters/setters. Mas tem alguns, e ali vai entendendo porque usaram daquela forma.
Vamos pegar a classe String. Notamos que tem apenas um campo imutável e alguns poucos métodos. O que eles têm de diferente? Elas não operam em cima de uma string existente, portanto não podem ser de instância. Mas por que eles estão nesta classe? Porque são métodos que produzem uma string de forma generalizada. Não quer dizer que tudo que gere uma string deve estar ali, mas aquilo que tem uma ligação muito direta com um objeto desse tipo.
Já parou para pensar que os construtores são estáticos? E algumas linguagens nem tem construtores de verdade, apenas métodos factories, que são estáticos. Muitos ou todos os métodos estáticos do exemplo acima provavelmente são factories.
Um exemplo que algumas linguagens adotam é poder manipular um objeto que pode ser nulo. Se o método fosse de instância daria erro, com um método estático é possível definir uma estratégia para este caso sem dar um erro. A possível ausência de um objeto é um bom motivo para ter um método estático.
Em C# temos métodos de extensão, que são estáticos. Estes métodos "simulam" métodos de uma classe sem pertencer a elas. Não vou entrar em detalhes aqui.
Tem uns casos que uma classe herdando de outra pode mudar um estado da API e você precisa saber disso. Ou seja, você precisa saber se aquela classe tem uma certa capacidade e tem um método na classe base que diz se tem ou não a capacidade, e quem herdar deve dizer se a capacidade está disponível ou não. Algumas pessoas dirão que isso viola o polimorfismo e Liskov, mas existe por aí.
Quase sempre é algo ruim, mas vamos dizer que uma classe guarde dados que vão sendo adicionados (em alguma coleção), então precisa de campo estático e pelo menos um método para adicionar, provavelmente outros para pegar, remover, etc. Quase sempre que precise fazer isso deveria ser em uma instância e não na classe, mesmo que a instância seja única por toda a aplicação. Mas se fizer precisa ter certeza que não haverá concorrência ou que tudo está preparado para funcionar corretamente dentro deste cenário. Um exemplo semelhante é ter um contador conforme vai criando novas instâncias ou por alguma outra ação que precise controlar contagem ou acumulação. Quase sempre é o jeito errado de fazer, mas tem por aí.
Uma obviedade é que classes estáticas possuem métodos estáticos, mas acredito que não é o caso da dificuldade de entendimento.
É bom notar também que os mais radicais proponentes de OOP dizem que nada deveria ser estático e isso é uma violação do paradigma. Eu já penso exatamente o contrário, ou seja, por padrão tudo deveria ser estático, até que se prove que não deveria. Veja bem, quase tudo não será estático, mas estático, quando usado adequadamente, é melhor, é mais eficiente e dá menos enrosco (evitando estado mutável). Lembre-se que um método estático tende a ser mais puro que um de instância que por padrão tem efeito colateral.
O default não deveria ser o que mais usa, mas sim o que deveria usar se não pensar sobre o assunto e adotar de qualquer jeito. É mais ou menos como devemos pensar sobre segurança, sabe, quando tudo deve ser considerado inconfiável, até que se prove confiável? A maioria das coisas serão confiáveis, mas você não pode pensar assim.
Por fim, quero te dizer que aprendeu um termo errado, já que a maioria das pessoas aprenderam errado e ensinam errado. Pelo menos em certo contexto, de Java, por exemplo, onde mais as pessoas usam ele errado. Para saber mais: https://pt.stackoverflow.com/q/269089/101.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).