Inte ett måste, men kan hjälpa skrivprestandan i avseende hastighet och minska lite på WAF - men den delen har nog minskat i betydelse med relativt stora SSD/NVMe-storlekar. Sådant var viktigare när SSD var 64-128 GB i storlek.
Jo förresten, det kan ha betydelse för flashlagring med QLC-minne då trim berättar för disken vilka sektorer vars kopplade flashminne kan friställas för SLC-cache då ju mer ledigt på disken ju större SLC-cache kan disken använda för snabb lagring innan skrivprestandan blir bedrövligt långsam (typ 40 MB/s) efter ett ganska lågt antal GB kontinuerlig skrivning
Ett alternativt sätt att visa vilka sektorer som inte användes och kunde kopplas bort så att bakomliggande flashen kunde raderas var att man helt enkelt skrev de lediga sektorer med bara '0' - vilket var enda sättet att tala om för SSD vilka sektorer som var 'lediga' innan TRIM-stödet implementerades.
I windows sägs officiellt att de kör TRIM endast på AHCI-enheter - dvs. SATA-SSD som inte finns i någon RAID-konstellation, inte på NVMe men förmodligen har drivrutiner för NVMe-lagring en ekvivalent funktion.
Windows brukar köra trim strax efter på filer som raderats och ibland en filsystem-TRIM enligt kalender (den kör också en enklare fildefragmentering typ 1 gång i veckan - väldigt diskret eftersom folk har fått islaget att man skall inte köra defragmentering på SSD - men problemet är att om NTFS skall hålla över tiden så måste det göras då och då ändå)
I linux så hanteras SATA-diskar och NVMe lika i avseende TRIM och där har man filosofi att man kör TRIM manuellt bara ibland och tex. när det har varit stora aktiviteter och mycket raderade filer eller schemalagt - och argumentet är att trim-processen på många flashlagringar kan dra ned prestanda ganska ordentligt medans TRIM-processen genomförs och därför bör göras vid tidpunkt när det inte gör så mycket om disken blir trög en stund. Givetvis går det att ha 'windowslik' TRIM direkt efter radering av filer även i linux med argumentet 'discard' i fstab för enheten.
Trim (i linux fstrim) fungerar också på krypterande volymen - men att nollställa sektorer längst ned närmast disken anses också något som sänker säkerheten då mönstret av nollade sektorer kan ge information om diskens innehåll - dvs hur välfylld den är och av mönstret också berätta vilken filsystem som används och därmed vilka positioner som har (meta)data som aldrig ändras och man kan ganska säker veta vad som finns skrivet där (som superblock eller första blocken i $MFT) - vilket underlättar attacken.