Lo más importante es que esté bien diseñado en el papel y de la forma más genérica posible, así el desarrollo, ya sea con una biblioteca multiplataforma o implementaciones separadas, es más sencillo.
Todas las soluciones tienen pros y contras. Tienes que valorar la curva de aprendizaje, si vas a querer hacer más tipos de apps además de juegos, si necesitas integrar características nativas, el rendimiento (especialmente si hay inteligencia artificial), el tamaño final de la aplicación (que un "minijuego" ocupe 20 megas por usar unity tiene guasa) y, por supuesto, el mercado potencial al que accedes (igual merece la pena sacrificar usuarios de windows si un desarrollo nativo de ios te da más beneficios).
Sobre HTML5/javascript, si usas WebGL la compatibilidad en móviles es reducida, y el Canvas va a pedales si hay varios elementos animados y quieres fluidez. Tampoco tiene hilos, y las comunicaciones de red están limitadas a HTTP y WebSockets. Pero es una opción si es muy sencillo, y con Apache Cordova podrías empaquetarlo para Android o iOS e incluso usar algunas características nativas.
Otra opción, para mí la favorita si quieres tener pocas plataformas pero bien controladas, es crearte un motor de juegos propio que exponga un API genérico (API que usarás en el diseño en papel). Ese API la implementas para cada plataforma (bien a pelo o usando por debajo una biblioteca nativa como cocos2d/spritekit en el caso de iOS). En ese caso, añadir funciones al juego, si no tienes que tocar el motor gráfico, es simplemente escribir las mismas líneas con la sintaxis de cada sistema (java y swift p.ej.)
Lo que sí es una locura es que la arquitectura de la app sea distinta entre plataformas, o que esté implementada directamente encima de una biblioteca concreta. Si el día de mañana dejan obsoleta una biblioteca o aparece otra mejor, si no tienes un API genérico te tocará modificar el código de todos los juegos, si tenías una capa de abstracción solo tendrás que cambiar la implementación de esa capa, las apps ni se enteran.