¿Cómo funciona el tamaño objetivo de la ciruela pasa?

A juzgar por los documentos, entiendo que la poda, en términos simples, solo permite deshacerse de información que no puede tener ninguna transacción de seguimiento.

Eso es incorrecto.

El proceso para la validación de bloques (simplificado) es:

• Recibir un bloque
• Encuentre todas las entradas del bloque en la base de datos de salidas no gastadas (el "conjunto UTXO") y verifíquelas (verificación de firma, etc.)
• Elimine todas las entradas del bloque del conjunto UTXO (ya que esas salidas ahora se gastan)
• Agregue todas las salidas del bloque al conjunto UTXO.

Una vez que se ha validado un bloque y se han aplicado sus efectos al conjunto UTXO, generalmente ya no necesitamos el contenido del bloque. Excepto por:

• Dárselo a otros nodos en la red que están tratando de averiguar qué sucedió en el pasado (lo que aún no puede hacer cuando está en modo de poda)
• Volver a escanear para encontrar transacciones históricas en la billetera (por ejemplo, después de importar una dirección o una clave), que es una función a la que renuncia al podar.
• Reorganizaciones. A veces se encuentra un bloque que no es sucesor del bloque anterior que vimos, sino que se ramifica más atrás. En este caso, debemos poder revertir los efectos de los últimos bloques antes de validar los nuevos bloques. Para retroceder, necesitamos el contenido de los bloques nuevamente. Esta es la razón por la que el cliente te obliga a conservar al menos 550 MB de datos en bloque, para que siempre puedas rebobinar los últimos días.

Así que TL; DR: es técnicamente posible crear un cliente que se reduce a un valor arbitrariamente pequeño, pero para evitar que los clientes tropiecen cuando ocurre una reorganización, el código lo obliga a conservar los datos de algunos días independientemente.