Le code que tu cites est obsolète. La documentation "introduction"  décrit le
fonctionnement des versions antérieures. Le controler a évolué. 

Tu peux te référer au manuel qui est à jour:
http://pmo.developpez.com/manuel/

Pour répondre à ta question concernant SQL

PMO tout comme PDO n'est pas la pour se substituer au langage SQL. PMO se
concentre donc sur son rôle crée une couche d'abstraction objet entre le sgbd,
et l'application.

La méthode getObjectByValue peut récupérer un Objet (et non enregistrement car
il embarque des méthodes) en fonction de l'attribut que tu désignes en
paramètre. Ca peut être login si t 'as une table utilisateur avec une colonne
login, tout comme ça peut être nomproduit si t'as une table produit, ou même
age si t'as une table personne etc ... PMO découvre le schéma de tes tables
dynamiquement, tu as donc des méthodes génériques.

Le nombre d'objets que tu crées en mémoire, dépend de l'optimisation de ta
requête. Si tu as une table avec 10000 enregistrements et que tu fais un
select  * sans critère forcément tu auras un nombre d'objets ultra importants.
Et c'est clairement pas une bonne idée, si tu veux juste modifier un login ..

Par contre si tu fais un select * from utilisateur where login="toto"; t'auras
qu'un seul objet à manipuler ;) Les contraintes sont les même qu'avec un
mysql_fetch_row hormis que tu manipules des objets. 

Pour le nommage setLogin, non étant donné que cette méthode est spécialisé à
une colonne login, alor que setAttribute te permet de manipuler n'importe
quelle colonne. 

Pour le $user->commit(), cela fait justement parti des dernières évolutions
comme $user->delete();

Si t'es vraiment interressé pour soumettre des évolutions, n'hésite pas à me
contacter sur mon mail perso, ou sur la liste de diffusion google du projet.
Jusqu'à maintenant j'ai essayé d'implémenter tout ce qu'on m'a soumis.