DISCLAIMER: I am not an SSD expert.
I had TRIM enabled initially (following the hack) on a 80GB Intel SSD (320 series) that I upgraded to in my 2009 MBP. When doing some research I came across some folks who suggested that this could actually lead to problems with the drive. Upon upgrading to the new Mac OS X (at the time I think it was Lion), I decided not to perform the enable TRIM hack. I really noticed no difference performance wise in day-to-day routines (comparing TRIM and no TRIM). After a few years of usage without TRIM, I performed a benchmark test (I reported it here, I can try and find it if you want) and found that my Read and Write were nominal with Intel's datasheet for my drive.
TRIM is explained on a lot of different web sites, and I recommend researching it. If in doubt, however, I would recommend not enabling TRIM because from what I've read, newer SSDs probably do not need TRIM OS support to function correctly for years. It seems like it was more of an issue at the birth of consumer level SSDs that is not as much of an issue anymore. That's my opinion, but re-read my disclaimer.
SSDs maintain a list of internal blocks that are marked as "clean" for writing. Writes are going to be of nominal performance if that list is mostly free. Performance degradation is really only going to crop up if you have large numbers of cyclic writes and erases to the drive. Why?
Because deleting files on a file system does not tell the SSD that the corresponding blocks are now invalid so the drive is doomed to treating the blocks are valid until such a point that new data is written over the logical locations where the old files were. Partial deletions and modifications to files don't have this problem because those are really writes to the file system, so the SSD is given the logical locations in such cases and immediately marks the blocks as invalid.
The point, I'm making here is that essentially if you aren't doing a lot of writes and deletions, your drive is going to have a pretty good idea of what is really valid block wise, but if you are, you'll eventually get to a point where there are many invalid blocks still marked as valid and so when the drive has to dish out new blocks, it has to consolidate partially written blocks into a single block before writing the data you requested to be written. At the end of the day, performance degradation is going to be largely dependent on your use-case.
I feel like many people don't understand properly what TRIM brings to the table that internal garbage collection can't achieve. It is not the fault of people though, it's really that what I just said about invalid blocks still being marked as valid after deletions is rarely explained properly in discussions of TRIM.
Wikipedia has a nice brief explanation of what I just said (in case my own isn't coming across to folk):