Depois de ler em cima (mais uma vez, deveria ter feito isso há muito tempo) implementando equals e hashcode corretamente cheguei a estas conclusões, que funciona para mim:

Se pré JDK 7: Prefere usar o Apache commons equalsbuilder e hashcodebuilder. (ou goiaba). Seus javadocs contêm exemplos de como usá-los no bom sentido.

Se o JDK 7 ++: Use a nova classe de utilitário Objetos

Mas, se estiver escrevendo para o modo de hibernação alguns requistes especiais aparecem (veja fontes mais abaixo). Entre eles estão o uso recomendado deinstancia de ao invés degetClass, devido ao hibernate criando proxys de subclasses que são carregadas com preguiça.

Mas, como eu entendo, se isso ocorrer, outro possível problema ocorre: O motivo para usar getClass é garantir a propriedade simétrica do contrato de igual. JavaDocs:

*It is symmetric: for any non-null reference values x and y, x.equals(y) 
 should return true if and only if y.equals(x) returns true.*

E usando instanceof, é possível não ser simétrico. Exemplo: B estende A. A é igual a um caso de checagem de A. B é igual a um exemplo de checagem de B. Dê A a e B b:

a.equals (b) -> true b.equals (a) -> false

Como implementar equals com hibernate sem arriscar perder a propriedade simétrica? Parece que não estou seguro quando uso o getClass, e não estou seguro quando uso o instanceof?

É a resposta para nunca adicionar membros significativos às subclasses e, em seguida, estar seguro ao usar instanceof (para hibernate that is)?

Fontes eu li:

Quais problemas devem ser considerados ao substituir equals e hashCode em Java?

Itens 7 e 8 em Josh Blochs livro excelente "Java eficaz",http://web.archive.org/web/20110622072109/http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf

Sobre o Java 7:http://www.javacodegeeks.com/2012/11/guavas-objects-class-equals-hashcode-and-tostring.html