I have some experience with these things as an OS architect and developer. Gino basically has it right.
At the disk level, files are made up of blocks. When an OS deletes a file, it adds those blocks to a free list and forgets the references to those blocks. The storage format of the free list and the file structure are not known to the SSD. After a block has been written for the first time, there is no real way for the SSD to tell whether it is still in use. It can't tell whether references exist to that block, because the SSD has no idea what format is used by the file system to store the references. The purpose of the TRIM command is to let the file system tell the drive (cooperatively) when a block is no longer used. In some cases, drives know enough to special-case a block consisting entirely of zeros, and can recognize "write a block of zeros" as a form of "poor man's trim".
Garbage collection does something completely unrelated, and doesn't really work unless TRIM is being used.
At the drive-level interface to the operating system, modern drives talk in terms of 1024 byte or 4096 byte blocks of data. Internally, they work in terms of 64 Kbyte or 128 Kbyte "pages". The SSD maintains a lookup table for each block telling it which page holds that block and where the block is found. This is necessary because the unit of erase on an SSD is that page, not the block. This is also the underlying mechanism that supports drive-level block compression (which is a really dumb idea, because it's the wrong place to do compression, but it makes for good marketing).
What happens over time is that you get pages that have only a few blocks of data that are still being used. The rest of the space in such a page cannot be used, because the drive can only erase full pages (it's a physical restriction down in the non-volatile memory design) and those one or two or three used blocks are standing in the way. What garbage collection does is move the used blocks to new (unused) locations in some other page so that the nearly free page becomes completely unused and can be erased. This relies on knowing which blocks are actually in use, which requires the TRIM command.
If 10% of your drive is full, you're good. You'll never see this. On bigger drives, it tends to be true that big media files get written once and then sit around for a long time without getting deleted. Because they don't get deleted we don't care about trim. Because they are big, they tend to get laid out as a bunch of full SSD pages and then one (on average) half-used SSD page. The wasted space in the pages arising from those files isn't enough that you notice.
What cruds up your drive is the stuff that is short-lived. Unless TRIM support is available, that stuff slowly but surely cruds up your drive because the drive can't tell which blocks are in use and which are free. Meanwhile, the file system generally prefers to write to previously unused blocks, because doing writes of full-page units is faster than writing a block at a time.
So:
1. YES, you really want TRIM support if it is supported correctly by your drive. If it isn't, replace the drive.
2. Apple's reluctant and belated support for TRIM on non-Apple drives is a disgrace. Every other major operating system has had this support for a decade or more. Once you do support for TRIM at all, it actually requires extra work to suppress TRIM support for third-party drives. This isn't an accident on Apple's part; it's a design decision.
3. Caveat: there are a very few SSD drives out there with known firmware bugs. These drives report to the OS that they support TRIM, but they do not actually do it correctly. On those drives, TRIM support must be turned off. The list of such drives is short, and the solution in every other OS is to maintain a blacklist of known-bad drives. I actually don't know of any SSD released in the last decade that has failed to support TRIM correctly.
4. Turning off TRIM in the file system is easy. At all the points where you would normally send a TRIM command, you either do nothing or you write a block full of zeros (to take advantage of "poor man's TRIM") instead.
My guess is that somebody within Apple decided to maintain a whitelist rather than a blacklist in the interest of reducing support burden, which makes sense because Apple fully controls the hardware choices that ship with their laptops and often uses devices that have Apple-specific firmware in the drive. Once this was in place, the pressure to fix more pressing bugs put this update off as "not important" because it only mattered to people who were "playing games" (from Apple's perspective) by installing third-party drives.
I don't know anything about Disk Sensei, but the useful thing that an application of this sort can do if written cleverly is to scan your filesystem, figure out which blocks are being used (that is: build a list) and then issue a TRIM command for every block that is not being used. This has the effect of issuing TRIM commands for all the blocks that OSX should have trimmed but did not. Once your drive is constipated, merely turning on TRIM support isn't enough; you actually have to go through and tell the drive which space is actually free.
A simple way to accomplish this without actually scanning the file system is to first enable trim support, then ask the operating system how much free space is available, then write non-zero files that consume (nearly) all of that free space (so filling it intentionally), and then delete those files. The act of deleting them induces the file system to issue TRIM commands on those blocks as the files are deleted, after which 90% or so of the unused blocks will have been TRIMmed. If 90% TRIMmed isn't enough to de-constipate your drive, you probably have more data on the drive than the drive can sensibly handle. Almost all file systems deteriorate quickly after the file system becomes 85% full (or so). The exact percentage depends on the file system and the frequency and size of file adds and deletes.
Hope some of this is a little helpful in providing understanding. Apple made sensible engineering decisions here, but they are decisions with expensive consequences for people who want to upgrade their systems.
Jonathan Shapiro, Ph.D.
Architect of the Coyotos and EROS operating systems