c'est plus facile à programmer sans bug graphique

Ca, c'est clair.

et ça permet d'avoir des animations

Ca, c'est moins clair. Il n'est pas absolument interdit de faire des animations quand il y a save&restore: quand il y a eu une animation (il _suffit_ de programmer le moteur de jeu pour - j'ai pas écrit que c'était _toujours_ facile, cf. le premier point ^^), il ne faut pas restaurer les anciens sprites et il faut réinitialiser les sprites sauvegardés.
(En même temps, quelle est la proportion de jeux utilisant des fonctions d'animation du fond ?)

si on utilise une bonne lib si

Ca, c'est faux
J'ai créé demo22 d'ExtGraph SVN exprès pour être un contre-exemple flagrant à cette quote. demo22 met en perspective:
* un bourrinage de redessin intégral (utilisant le tilemap engine);
* un bourrinage de save&restore tant que le fond ne bouge pas (il bouge tous les deux ticks d'AI5, donc à un peu moins de 10 Hz avec les réglages par défaut).
Je veux dire par "bourrinage" qu'il n'y a aucune synchro avec l'écran (écriture directe dans les planes), et qu'il n'y a pas non plus un gaspillage de CPU pour simuler le moteur du jeu.

Evidemment, le mode intelligent, comprenant save&restore, fait plus de frames en 15s. Même si comme je viens de l'écrire, dans un programme réel, l'écart serait moindre.
Si j'avais utilisé des sprites préshiftés pour le mode bête, le mode intelligent serait quand même plus rapide. Ce n'est pourtant pas que les fonctions d'ExtGraph, que ce soit le tilemap engine ou les sprites préshiftés, sont lentes