Je suppose que c'est un moyen de rendre les applications qui ne l'utilisent pas du tout légèrement plus performantes. Voici ma réflexion à ce sujet.
Les systèmes d'exploitation x86 (et j'imagine que d'autres) doivent stocker l'état du FPU sur le changement de contexte. Cependant, la plupart des systèmes d'exploitation ne prennent la peine de sauvegarder / restaurer cet état qu'après que l'application a tenté d'utiliser le FPU pour la première fois.
En plus de cela, il y a probablement un code de base dans la bibliothèque mathématique qui mettra le FPU dans un état de base sain lorsque la bibliothèque est chargée.
Donc, si vous ne liez pas du tout de code mathématique, rien de tout cela ne se produira, par conséquent, le système d'exploitation n'a pas du tout à sauvegarder / restaurer l'état FPU, ce qui rend les changements de contexte légèrement plus efficaces.
Mais juste une supposition.
EDIT: en réponse à certains commentaires, la même prémisse de base s'applique toujours aux cas non FPU (la prémisse étant qu'il s'agissait de faire légèrement mieux les applications qui n'utilisaient pas libm).
Par exemple, s'il existe un soft-FPU qui était semblable aux premiers jours de C. Ensuite, avoir libm séparé pourrait empêcher beaucoup de code volumineux (et lent s'il était utilisé) d'être lié inutilement.
De plus, s'il n'y a que des liens statiques disponibles, un argument similaire s'applique, selon lequel les tailles exécutables et les temps de compilation seront réduits.