In the early days with hard disks, it was all fairly straightforward. The directory system used by the operating system (e.g. FAT, FAT32 or NTFS) kept a log of what files were held on the disk and where they were. When a file was deleted, to speed things up all the OS did was to remove the entry from the directory and effectively it was gone, even though the data remained on the disk. This didn't matter at all because this space was now free to be written on, even though it held old data. Whether it held 00000000000 or 012A62376F or whatever didn't matter at all, so why bother wiping the disk.
So here's the short answer:
With SSD's because they move data around in the background for optimisation purposes, the above mechanism no longer works. You need a way to tell the drive what data has been deleted, so it doesn't move junk around unnecessarily. That is what the Trim command does. It simply lets the drive know what data is no longer needed, so the SSD controller can deal with it appropriately.
The longer answer (if you are interested) is this:
[SNIPPED]
Chippy, thanks for the explanation. Your description of GC is very similar to something in my past, the GC done by Applesoft BASIC on the old Apple II's. It was something BASIC programmers hated, since it was done by the system and you had no control over WHEN it happened. So for no apparent reason, if the program had used enough memory that it needed cleaning up, your program would bog down until GC was finished.
So now the SSD makes more sense. I was viewing it as an HDD, not a memory space. Again, thanks for clearing that up.