Prenons le cas "simplifié" ou on a simplement le moteur 2 qui suit le moteur 1.
La consigne pos2 sera donc égale à pos1
Hors, il y a une certaine latence entre le moment où le moteur 1 à bougé, et celui ou le moteur 2 bougera (durée de la mesure, du traitement par le microcontroleur, de l'inertie du moteur 2 (inductance et inertie mécanique)).
Bref, le moteur 2 sera toujours "en retard" par rapport au moteur 1.
Si on prends en compte la vitesse, le moteur 2 pourra "deviner" où vas le moteur 1, et ainsi ne plus être en retard (il y aura juste une petite avance ou un petit retard quand le moteur 1 change de vitesse).
La même chose devrait s'appliquer ici avec les moyennes : la prise en compte de la vitesse réduit donc le retard.
Plus généralement, en contrôle, si on sait prévoir une partie de l'erreur (ici la présence d'une vitesse), le mieux est de la compenser d'office (feed forward), et de n'asservir que l'erreur restante.
Par exemple pour un bipède, en déplacement quasi-statique (ie en équilibre permanant), il est bien utile de pré-calculer le couple nécessaire pour contrer la gravité, et de l'ajouter au couple obtenu en sortie d'un PID sur l'erreur de position d'une articulation, plutôt que de juste utiliser un PID. Dans ce dernier cas, pour compenser la gravité, il faut soit un P titanesque (overshoot important), soit attendre d'accumuler une grande partie intégrale (risque de tomber avant que l'intégrale soit suffisante, et inertie importante lorsqu'on veut changer de position)
