Tout est sprite sur la Lynx, y compris le fond d'écran (sauf à taper sauvagement dans le buffer écran comme Vince l'a fait dans une de ses démos).
Par exemple : la fonction DrawFBox du kit BLL, c'est un sprite 1x1 zoomé pour être à la bonne taille.
Bon, maintenant, je n'ai pas vraiment de réponse "approuvée et validée" à tes questions coopy par ce que :
1- je ne suis pas encore arrivé aux limites proprement (j'y suis avec Space Dance, mais c'est très spécial : monde virtuel tès très en hauteur...)
2- quand j'y suis arrivé, c'était parce que c'était mal programmé (pas de liste chainée, trop de code annexe autour, possibilité de faire mieux...)

Une chose est sure : il faut au maximum utiliser les listes chainées.
De plus, même si la console gère le clipping automatique, il vaut mieux désactiver soit même certains sprites (= non affichable) quand le monde est trop grand, voire changer son sprite de départ.

En fait, le gros problème de la Lynx, c'est la ram : tu peux chainer une tonne de sprites, mais pas différents, car tu n'auras pas la place en mémoire.
En effet : il y a certes 64ko de RAM, mais il faut enlever 8ko pour le buffer physique, 8ko pour le logique et éventuellement 8ko pour le buffer de collision, ce qui te laisse juste 48 ou 40ko au mieux.
Pour info : un fond 160x102, c'est 2ko si c'est moi qui le fait (tout simple avec des applats), mais ça peut monter à plus de 7ko pour les graphs de tempi que tu connais (tramage...). La compression doit être du type PC1 je pense.