Primero busqué en Google y leí estas preguntas:
Creación de contratos múltiples o contrato único con estructura
¿Por qué hay tantos ejemplos que utilizan contratos separados (por ejemplo, contratos de venta multitudinarios en zepelín...)? SI tengo todo esto bien en la mayoría de los casos, tendría sentido NO usar contratos separados. Ni siquiera tendría sentido usar libs e interfaces. En mi humilde opinión, una interfaz tiene sentido si no tengo que pagar gasolina para la ejecución. Pero estamos en una cadena de bloques y queremos mantener los contratos lo más "delgados"/"ligeros" posible. Por lo tanto, solo copiaría las funciones de código que necesito de una biblioteca (solo usaría la biblioteca completa si uso todas las funciones). Use la interfaz solo para verificar y depurar...
Hay dos razones separadas por las que querría separar su lógica en más de un contrato/bibliotecas/etc.
1- Modularidad, facilidad de uso, facilidad de mantenimiento. Si renuncia al uso de bibliotecas o la herencia de otros contratos, su código será un archivo enorme con docenas de funciones, que es difícil de mantener, leer, reutilizar, etc.
2- La implementación de contratos padre/hijo tiene más que ver con la lógica de su código. Por ejemplo, para una aplicación de ofertas, podría tener un contrato que almacene todas las ofertas en curso con sus datos correspondientes (postores, oferta ganadora, etc.) O, podría crear contratos de ofertas en los que cada uno tenga la lógica propia y luego, un contrato principal que mantiene una referencia a cada contrato de licitación que se crea.
Cada enfoque tiene sus propias ventajas y desventajas y realmente depende de cuáles sean los requisitos para su aplicación.