¿Por qué una sola instancia de Jedis no es segura para subprocesos?

Una sola instancia de Jedis no es segura para subprocesos porque se implementó de esta manera. Esa es la decisión que tomó el autor de la biblioteca.

Puede verificar el código fuente de BinaryJedis, que es un súper tipo de Jedis https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/BinaryJedis.java

Por ejemplo estas líneas:

public Transaction multi() {
    client.multi();
    client.getOne(); // expected OK
    transaction = new Transaction(client);
    return transaction;
}

Como puede ver, el campo de transacción se comparte para todos los subprocesos que usan la instancia de Jedis y se inicializa en este método. Posteriormente esta transacción puede ser utilizada en otros métodos. Imagine que dos subprocesos realizan operaciones transaccionales al mismo tiempo. El resultado puede ser que otro subproceso acceda involuntariamente a una transacción creada por un subproceso. El campo de transacción en este caso es un acceso de estado compartido al que no está sincronizado. Esto hace que Jedis no sea seguro para subprocesos.

La razón por la que el autor decidió hacer que Jedis no sea seguro para subprocesos y JedisPool sea seguro para subprocesos podría ser proporcionar flexibilidad a los clientes, de modo que si tiene un entorno de un solo subproceso puede usar Jedis y obtener un mejor rendimiento o si tiene un entorno de subprocesos múltiples puede usar JedisPool y obtén seguridad para subprocesos.