Você pode esperar diferenças drásticas se armazenar em cache o que é bom para ser armazenado em cache e evitar o armazenamento em cache de dados que não devem ser armazenados em cache. Assim como a beleza está nos olhos de quem vê, o mesmo acontece com a performance. Aqui estão vários aspectos que você deve ter em mente ao usar o provedor de cache de segundo nível do Hibernate AS:

Sem serialização personalizada - uso intensivo de memória
Se você usar o cache de segundo nível, não poderá usar estruturas de serialização rápidas como o Kryo e terá que ficar com o java serializável, o que é péssimo.

Além disso, para cada tipo de entidade, você terá uma região separada e, dentro de cada região, terá uma entrada para cada chave de cada entidade. Em termos de eficiência de memória, isso é ineficiente.

Não tem a capacidade de armazenar e distribuir objetos avançados
A maioria dos caches modernos também apresenta funcionalidade de grade de computação, tendo seus objetos fragmentados em muitas partes pequenas, diminuindo sua capacidade de executar tarefas distribuídas com co-localização de dados garantida. Isso depende um pouco do provedor do Grid, mas para muitos seria uma limitação.

Desempenho abaixo do ideal
Dependendo de quanto desempenho você precisa e que tipo de aplicativo você está tendo, usar o cache de segundo nível de hibernação pode ser uma boa ou uma má escolha. Bom em termos de plug and play...." meio que..." ruim porque você nunca vai espremer o desempenho que teria ganho. Também projetar modelos ricos significa mais trabalho inicial e mais OOP.

Recursos de consulta limitados no próprio cache
Isso depende do provedor de cache, mas alguns provedores realmente não são bons fazendo JOINs com cláusula Where diferente do ID. Se você tentar construir um índice de memória para uma consulta no Hazelcast, por exemplo, verá o que quero dizer.