Je connais bien ces deux sources et j'ai hésité à les citer. Ceux qui recommandent de laisser de l'espace libre se basent sur de vieilles technologies ou de vieux documents. Je ne dis pas qu'ils ont tort, mais les algos des firmwares de contrôleurs de SSD n'ont cessé de s'améliorer depuis pour en optimiser l'usage et réduire l'usure.
L'impact des systèmes de fichier est à mon humble avis totalement négligeable sur un disque connecté en PCIe (NVMe). Si on perds même 10% de vitesse à l'écriture (ce qui est déjà conséquent), ça reste dérisoire (passer de 2,5 Gio/s à 2,25 Gio/s ne fait pas une différence si cruciale que ça pour la plupart des utilisateurs). C'est en tout cas ce que je constate, puisque je fais partie des utilisateurs pour lesquels le NVMe est indispensable. Un rush ARRIRAW 6.5K nécessite un débit constant (en lecture) d'environ 740 Mio/s, impossible à atteindre en Sata. Pour deux rushs lus en même temps, on double le débit. Or que le disque soit quasiment vide ou totalement plein, ça ne change rien de perceptible aux performances, que ce soit en lecture ou en écriture lors du transfert des rushs.
L'impact est sans doute beaucoup plus perceptible sur un disque comprenant des centaines de milliers de petits fichiers, obligeant à la recherche des blocs libres en parcourant les noeuds. Mais encore une fois, ça dépend du système de fichier. Entre un système lent basé sur une table d'allocation (FATxx, exFAT), et un système organisé en arbre comme NTFS, EXT4, ReFS ou ZFS, l'impact n'est pas le même.
Je vous retrouverais l'article qui explique très en détail le fonctionnement d'un SSD et pourquoi il ne faut jamais essayer de défragmenter un tel dispositif. D'ailleurs, il me semble que sous Windows, on ne peut pas défragmenter un SSD, on peut juste faire un TRIM (pour indiquer au contrôleur les blocs non utilisés et qu'il puisse gérer son optimisation).