Using the disable eval setting crashes the module, but the module's use of eval() is redundant anyway

just duplicated using the less specific entity hooks.

This is not correct. The hook are all fired at different times. The reason we have to eval these hooks into existence is because there is no way of decrypting the entity prior to these hooks being fired. This can cause all sorts of problems. The hooks that you think are missing are not there because for these hooks we can decrypt the entity first - so we don't need to eval them into existence.

This is all documented in the module. See

/**
 * Implements hook_module_implements_alter().
 *
 * The Field Encrypt module decrypts and encrypts entity data by implementing
 * regular entity hooks. The order in which the hooks are fired determines
 * whether the entity data is encrypted or decrypted. It is important for that
 * for other implementations of these hooks that data is encrypted and decrypted
 * at the right time.
 * - field_encrypt_entity_storage_load() needs to be the first implementation
 *   of hook_entity_storage_load() so other implementations can use decrypted
 *   data.
 * - field_encrypt_entity_presave() needs to be the last implementation of
 *   hook_entity_presave() so other implementations can use decrypted
 *   data.
 * - field_encrypt_entity_insert() and field_encrypt_entity_update() can not
 *   be triggered in the correct location as hook_ENTITY_TYPE_insert() and
 *   hook_ENTITY_TYPE_update() are triggered first. Field encrypt tries to get
 *   around this by dynamically declaring hook_ENTITY_TYPE_insert() and
 *   hook_ENTITY_TYPE_update() implementations.
 *
 * @see field_encrypt_entity_storage_load()
 * @see field_encrypt_entity_presave()
 * @see field_encrypt_entity_insert()
 * @see field_encrypt_entity_update()
 * @see _field_encrypt_define_entity_hooks()
 * @see \Drupal\Core\Entity\EntityStorageBase::invokeHook()
 */
function field_encrypt_module_implements_alter(&$implementations, $hook) {