Вот вроде начинаете правильно излагать, а потом в сторону уходите, делая сомнительные предположения. Давайте по фактам. Тут кто-то очень верно упомянул АЛГОРИТМЫ...
Мы знаем принцип работы HDD (позиционирование БМГ на пластинах), от чего становится понятным принцип и цель дефрагментации - убрать лишние перемещения БМГ, получив последовательные операции чтения (для блоков одного файла, для файлов одного каталога, перемещение "популярных" файлов в начало диска и т.п. - тут раздолье для разных алгоритмов). Программно можно задавать место хранения данных. (опять же, с поправкой на то, что контроллер HDD на низком уровне обрабатывает доступность сектора, пометки ББ и т.п.)
На SSD нет БМГ, нет перемещения, нет паразитного времени ожидания. Есть в лучшем случае распределение по каналам и количество циклов перезаписи каждой ячейки. Именно контроллер определяет, куда писать данные. По какому алгоритму он это делает - известно наверняка только инженерам производителя. Как отрабатывает сборщик мусора - мы тоже не знаем. Но точно знаем, что необходима поддержка TRIM, и она есть во многих ОС (в винде начиная с 7).
А теперь предположение)
Сторонний дефрагментатор может влиять на расположение файла на HDD - именно тут применяется оптимизированный алгоритм. Для SSD оптимизация алгоритма может быть применена разве что к моменту подачи TRIM.
Что-то забыл?

90% это сколько лет они так фрагментировались, я как то проверял с помощью Auslogics Disk Defrag диск файлопомойку который никогда не дефрагментировал с момента его покупки 5 лет назад и программа показали фрагментацию чуть больше 30%
В любом случае дефрагментацию с большой натяжкой можно использовать на HDD и абсолютно бесполезное действие на SSD и вообще фуфло вся эта дефрагментация, функция устаревшая минимум лет на 10