¿Qué te aportan en realidad las anotaciones de tipo y un comprobador como mypy?

Las anotaciones de tipo son marcas que Python no comprueba en tiempo de ejecución; un comprobador estático como mypy o pyright las lee y reporta incoherencias antes de que el código se ejecute. La recompensa es cazar clases enteras de errores, como un None circulando donde se requiere un valor, además de un autocompletado y una refactorización mucho mejores. También documentan la intención de forma más fiable que un docstring, que se desactualiza.

En tiempo de ejecución son básicamente comentarios, porque Python las guarda y sigue adelante. El valor viene de que un comprobador las lea. Mypy caza los bugs aburridos que causan la mayoría de las incidencias, sobre todo valores opcionales que llegan a código que asume un objeto real, y firmas que se desalinean tras una refactorización en la que se escapó una llamada. En una base de código que heredé, con unas sesenta mil líneas y sin anotaciones, activamos mypy con casi todo desactivado, lo metimos en CI para que el número de errores no pudiera crecer, y luego fuimos tipando módulo a módulo empezando por las fronteras por donde entran los datos. El modo estricto llegó después, paquete a paquete, con overrides por módulo en pyproject. A los seis meses cazó una desreferencia de None en una ruta de pagos durante una revisión y no a las dos de la mañana. El otro beneficio que la gente infravalora es el soporte del editor, porque con tipos de verdad, renombrar e ir a la definición funcionan, y eso cambia lo dispuesto que está el equipo a refactorizar cualquier cosa.