L'avantage de l'existence dynamique de l'objet au dela de la variable créée que tu as mentionné est une raison valable effectivement. Mais le vrai avantage de cette approche, est que la fonction renvoie un pointeur plutôt que l'entiereté de la Struct. Le passage par argument comme le retour de fonction en C s'éxecute par copie de la valeur.
Donc dans le cas
Vector create_vector()
le compilateur va générer du code machine qui s'occupe de copier l'entiereté de la Struct qui était initialisiée sur le stack de la fonction dans la variable qui récupère le valeur retournée par la dite fonction. Si une struct possède beaucoup d'éléments (comme par example un tableau statique) ce processur peut être couteux en terme de temps/performance. Tandis que dans le cas
Vector* create_vector();
Le compilateur va générer du code machine qui copie simplement le pointeur de la struct dans la variable en dehors de la fonction. Un pointeur étant juste une adresse mémoire, ce processus est virtuellement instantané et donc préfèrable à l'approche précédente si le but est d'avoir un programme optimal niveau performance (qui bien que n'étant pas forcément la priorité numéro une dans la manière qu'on a de vous apprendre à coder en C, c'est tout de même quelque chose de très important à comprendre et à faire dès que possible dans vos programmes en C).
EDIT: Je tiens à préciser que l'approche de renvoyer un pointeur est préférable et fonctionne uniquement si l'objet pointé par ce pointeur a été alloué dynamiquement au préalable (donc par le biais de malloc/calloc/realloc). En aucuns cas vos fonctions doivent retourner un pointeur sur un variable qui a été initialisée statiquement dans la fonction. Une fois que la fonction a terminé son exécution, ces données statiques sont déasallouées, de ce fait, toute utilisation d'un pointeur qui pointe sur cette mémoire obsolète va produire une corruption de mémoire. Faites bien attention à ça, retournez des pointeurs sur de la mémoire dont vous êtes certain qu'elle sera toujours accessible dans le futur.
