Pour le serveur OVH, s'il est effectivement en 10Gbps, avoir plusieurs connexions peut permettre d'obtenir une part plus importante en cas de saturation.

Pour les serveurs 40Gbps / 100Gbps, normalement on doit pouvoir obtenir le débit max avec une seule connexion, à condition que la fenêtre TCP puisse être assez grande compte tenu de la latence (parfois l'option -w peut aider, mais certains serveurs échouent).
Par exemple, même sous Windows :
Sinon je note que tous les tests iperf sont en IPv4 ici, normalement l'IPv6 devrait être préférée.

Là c'est peut-être la latence qui limite avec la taille de fenêtre TCP par défaut, surtout sous Windows.
Est-ce que ce n'est pas mieux avec "-w 16M" ?

Peut-être qu'il y a quelques pertes, qui font facilement chuter le débit au niveau de l'algo de congestion TCP.
Un test sous Linux ou WSL donnerait plus de détails (colonnes avec les "retry" et la fenêtre TCP), et permettrait aussi de tester BBR ("sudo iperf3 -C bbr ...") qui tolère beaucoup plus les pertes.
Il y a aussi la possibilité de limiter le débit pour voir si c'est plus stable, par exemple avec "-b 7G".

Avec les débits vers le serveur OVH, la limitation à 7Gbps ne sert absolument à rien pour lui (c'est sur ping.online.net qu'il fallait faire ce test).

De mon côté il n'est pas si horrible, ça plafonne toujours à entre 1,7Gbps et 2,5Gbps (mais parfois le débit a du mal à monter).
Il y a parfois quelques retry au début, mais rien de dramatique.
Le serveur ne semble pas vouloir du "-w", et avec les 12ms de ping la taille de la fenêtre TCP peut plus facilement limiter.

Pour tes tests Linux :
 - c'est mauvais vers ping.online.net, malgré aucune perte
 - sbg.proof.ovh.net atteint les 2Gbps (limite du serveur ?), avec une window de  "4.39M"
Quelle est le ping vers ces serveurs ?
Comme tu as choisi un serveur à Strasbourg, je suppose que tu es par là, mais peut-être que la route passe par Paris.
Dans les deux cas, il faut probablement des gros buffers pour que les débits montent, mais ça n'explique pas pourquoi Windows se comporterait mieux pour ping.online.net, et Linux pour sbg.proof.ovh.net.

Les tests en parallèle ne sont pas utiles tant qu'on ne comprend pas ce qui se passe.
Les tests avec le débit qui chute au milieu seraient intéressants sous Linux avec les retry, sous Windows on n'a aucune information.

7ms vers Orange Strasbourg (le speedtest au départ), 11ms vers OVH Strasbourg, et 15ms vers Paris, c'est bizarre, peut-être qu'un traceroute expliquerait des choses.
Avec cette latence il faut des gros buffers et pas de perte (avec cubic, sous Linux le BBR serait mieux) pour que les débits puissent être importants.