Pues como hablamos de experiencia te diré que en la mía las variables Integer tienen cierto sentido para determinados que no parecen tan descabellados, cómo te ponía de ejemplo los contadores, también un ejemplo de esto son las variable que utilizamos para codificar determinadas cualidades de nuestros programas, que a lo mejor con 5 o 6 valores nos vale para codificar esto, yo proyectos de juguete creo que no hago, menos cuando cómo de esos "proyectos" de juguete.
Como bien dices si un proyecto es grande lo mejor es recurrir a VB, si un proyecto grande lo quieres meter en excel pues será ineficaz, por proyecto grande entiendo uno que requiera múltiples conexiones a DBS bien con conexiones tipo ADO u otro tipo de conexiones, con varias interfaces de usuario, formularios, módulos, definición de librerías, etc, por otra parte para un rankiano que quiera hacer esto en su casa el VB 6 enterprise Edition no tiene sentido, cuando se puede bajar el VB Express 2010 de registro gratuito con unas pocas limitaciones que en la práctica en un entorno doméstico apenas se aprecian.
Si lo que esperas es que un rankiano cree todo un software con varios formularios, módulos y gestione conexiones a DBs, creo que tendrá los suficientes conocimientos como para prescindir del excel en este aspecto y por otro lado dudo que todo esto lo vaya a usar sólo para hacer una pequeña simulación de una estrategia o volcado de datos de forma sencilla que parece ser que es lo que la mayoría desea al acudir a estas herramientas que estamos tratando aqui.
Por otro lado diré que entiendo los usos del Long y no digo que sea preferible este tipo de variables a los Integer, simplemente digo que cada una tiene su función, ahora, que sean la excepción las Integer tampoco, y por otro lado si lo que deseas es codificar grandes números sin problemas de precisión puedes recurrir a los Double, no voy a hablar ya de la gestión de memoria que eso daría para otro tanto, pero efectivamente hoy día problemas de memoria ya apenas encuentras, lo que no quiere decir que por ello se deba abusar de la capacidad de computación, yo prefiero que un programa funcione con los mínimos recursos prescindibles, y por experiencia te digo también que la ley de Pareto se cumple también en programación (20% del tiempo diseñando, 80% del tiempo depurando), claro que un buen diseño del software disminuye el tiempo global dedicado al proyecto, también hay que asumir que el proceso de depuración es más largo y engorroso que la propia programación.
lo mejor es construir los programas como os lego, por piezas XD, esa creo yo que es la auténtica clave para ahorrar tiempo de depuración, cuanto mejor diseñes tu clases y objetos (casos de POO) o más pequeñas y básicas sean tus funciones (caso PE) mejor resultará el programa y menos errores se cometerán (obviamente siempre harán falta clase, rutinas, módulos, funciones... que implementen las más pequeñas) pero como te digo creo que esto se sale un poco del tema ¿no? que son las macros de excel, aunque estaría muy bien tratar un poco la programación incluido C# y en general Visual Studio (F#, VB, etc), ya que cada vez más el software financiero que conozco y manejo tiende a construirse con estos lenguajes, incluido aplicaciones de software libre
PD: cada uno tiene su forma de programar, eso es indiscutible, sólo pretendía completar un poquito la información dada, puesto que hablabas de definición de variables y sólo he aportado los que a mi juicio son dos tipos básicos de variable, con ello no pretendía ofender a nadie, y si así ha sido me disculpo.
PD: por cierto el tema de los bits y cuánta información se puede codificar con un tipo u otro se puede ver aqui:
Integer: http://msdn.microsoft.com/es-es/library/06bkb8w2(VS.80).aspx
Long: http://msdn.microsoft.com/es-es/library/y595sc15(VS.80).aspx
según leo aqui en sistema de 32 bits el Integer es más eficiente, pero como digo cada programador es un mundo...
s2