On (là, je ne sais honnêtement plus qui) conseillé de jeter au moins un oeil aux codes sources de frameworks éprouvés: c'est effectivement une excellente idée, et cela a été très instructif. Si tu aimes taper du code plus que sortir des projets (pas de mal à cela), je te conseille de suivre cette même directive: cela te permettra de voir la structure choisie par le framework, et cela t'apprendra beaucoup 
Pour le coup des "p'tits jeunes", je te rejoins: avant d'utiliser un framework, il faut en maîtriser le langage de base. C'est pas une usine magique à code, c'est seulement un ensemble d'outils écrits dans un langage (à connaitre donc, avant d'utiliser ces outils).
Un outil de déploiement, au fond, fait automatiquement ce que tu te farcis manuellement: minimifier ce qu'il faut, l'optimiser au besoin, synchroniser les BDD, regarder ce que le FTP contient, mettre à jour/uploader/supprimer ce qu'il faut, archiver ce qui existe avant de le remplacer (pour permettre un rollback du déploiement), lancer un mail aux membres de l'équipe avec les changements qui ont eu lieu, poster une news avec ce même changelog,...
Toutes ces fonctions ne sont pas forcément là,de base (pas sûr que Rocketeer ajoute une news à un wordpress à chaque déploiement), mais tu peux intégrer ces fonctionnalités à ces outils: au lieu de faire tout l'outil de déploiement, tu ne fais que la commande que tu veux exécuter: le reste est du ressort de l'outil de deploy.
C'est très pédagogique pour la structure du projet (séparer clairement les tâches, chainer des outils qui font une et une seule chose, et qui le font bien,...)
Si le framework ne fait pas ce que tu attends, vérifie que tu l'utilises bien, qu'il est bien à jour, que ce n'est ni un bug ni une feature request, et au besoin, change de framework: cela ne te coutera pas si cher que cela, car ton code métier (celui spécifique au jeu) ne changera peu voire pas.
[Edit]: zut, j'avais pas vu la 3e page! Donc je dis en fait comme tout le monde:
Si t'aimes apprendre, lit les codes sources des frameworks, et bidouille-les un peu: t'apprendras 10x plus vite
Il est vrai que pour la légèreté, un framework répandu pourra être bien plus performant qu'une bidouille perso pour les raisons évoquées par Sephi, auxquelles j'ajouterai que le temps du développeur est plus précieux que celui de la machine: des pages 10% plus lentes valent mieux que 6 mois de dev sur le projet (point de vue industriel).
@Sephi: le but n'est pas d'avoir le même contrôleur (qui fait les requêtes SQL) qu'on soit en HTML, API ou RSS, mais de sortir la génération du HTML/JSON/RSS/autre du code-serveur (PHP, Ruby, etc). Le contrôleur du site se contente de cracher du DOMDocument (XML) au lieu de cracher parfois du JSON, parfois du XML, parfois du HTML... On sort la vue du code PHP pour la mettre dans le XSL, tout comme on sort le Model pour le mettre dans un SGBD.
Mais bon, c'est peut-être qu'une question de points de vue... Utiliser XSL me semble plus intéressant qu'un paquet de code PHP pour les templates, d'autant que le XSL sera processé par un code C++ et non par des lib PHP, plus lentes.
Pour le coup des "p'tits jeunes", je te rejoins: avant d'utiliser un framework, il faut en maîtriser le langage de base. C'est pas une usine magique à code, c'est seulement un ensemble d'outils écrits dans un langage (à connaitre donc, avant d'utiliser ces outils).
Un outil de déploiement, au fond, fait automatiquement ce que tu te farcis manuellement: minimifier ce qu'il faut, l'optimiser au besoin, synchroniser les BDD, regarder ce que le FTP contient, mettre à jour/uploader/supprimer ce qu'il faut, archiver ce qui existe avant de le remplacer (pour permettre un rollback du déploiement), lancer un mail aux membres de l'équipe avec les changements qui ont eu lieu, poster une news avec ce même changelog,...
Toutes ces fonctions ne sont pas forcément là,de base (pas sûr que Rocketeer ajoute une news à un wordpress à chaque déploiement), mais tu peux intégrer ces fonctionnalités à ces outils: au lieu de faire tout l'outil de déploiement, tu ne fais que la commande que tu veux exécuter: le reste est du ressort de l'outil de deploy.
C'est très pédagogique pour la structure du projet (séparer clairement les tâches, chainer des outils qui font une et une seule chose, et qui le font bien,...)
Si le framework ne fait pas ce que tu attends, vérifie que tu l'utilises bien, qu'il est bien à jour, que ce n'est ni un bug ni une feature request, et au besoin, change de framework: cela ne te coutera pas si cher que cela, car ton code métier (celui spécifique au jeu) ne changera peu voire pas.
[Edit]: zut, j'avais pas vu la 3e page! Donc je dis en fait comme tout le monde:
Si t'aimes apprendre, lit les codes sources des frameworks, et bidouille-les un peu: t'apprendras 10x plus vite
Il est vrai que pour la légèreté, un framework répandu pourra être bien plus performant qu'une bidouille perso pour les raisons évoquées par Sephi, auxquelles j'ajouterai que le temps du développeur est plus précieux que celui de la machine: des pages 10% plus lentes valent mieux que 6 mois de dev sur le projet (point de vue industriel).
@Sephi: le but n'est pas d'avoir le même contrôleur (qui fait les requêtes SQL) qu'on soit en HTML, API ou RSS, mais de sortir la génération du HTML/JSON/RSS/autre du code-serveur (PHP, Ruby, etc). Le contrôleur du site se contente de cracher du DOMDocument (XML) au lieu de cracher parfois du JSON, parfois du XML, parfois du HTML... On sort la vue du code PHP pour la mettre dans le XSL, tout comme on sort le Model pour le mettre dans un SGBD.
Mais bon, c'est peut-être qu'une question de points de vue... Utiliser XSL me semble plus intéressant qu'un paquet de code PHP pour les templates, d'autant que le XSL sera processé par un code C++ et non par des lib PHP, plus lentes.