These drives use the SandForce controller, so have their own 'housekeeping' mechanisms, so TRIM is not required to maintain performance.
I hate to break up the SandForce love train, but these claims are simply not true. While wear-leveing is important in the long run, in the short run it is not what causes SSD's to slow down, and claiming that the SandForce controller's garbage collection is on par with TRIM is simply wrong.
An SSD cannot overwrite a block with data, and therefore needs to empty it before new data can be written to the block. Because of how SSD's can write to the smaller pages but can only erase blocks, the "overwrite" process involves copying all relevant pages from an old block to a new block and then filling out the rest of the blank pages in a block. This is a slow process, and is best done during idle, instead of on-demand during a write, so the industry needed to come up with a solution to this and the answer was TRIM.
This whole problem arises because of the way traditional magnetic media worked: it had no overwrite penalty, so when something was deleted, the only thing that happened was that it's entry was removed from the directory (a pointer to its actual location) while the actual bits of data were left untouched sitting in whichever block they were residing in. Again, with no overwrite penalty for magnetic media, this worked great because you could just overwrite the block when the time came and nobody was the wiser. Since this isn't true for SSD's, TRIM came along to manually clear out blank pages/blocks and consolidate what was left for faster performance. The HUGE benefit of TRIM is that OS knows which allocated pages/blocks are still being used and which can be discarded, since it is in control of file management and knows what's been deleted and what hasn't been.
SandForce and it's ilk arose because both Apple and Microsoft were a little slow implementing TRIM support in their OS's and people wanted to use SSD's in their computers as soon as they were available without waiting for Lion or Windows 7, so HD-based "garbage collection" arose as a stopgap. The problem with it is that the HD can't know which allocated blocks are still in use and which aren't, so it only does it's best to consolidate all active pages and hope for the best. You'll notice the decreased long-term optimization of SandForce when you are running a mostly full drive, because it won't have as much space to get lucky with. This is why SandForce drives come with "scratch" areas pre-cordoned off (i.e. reported capacity of 240GB despite having 256GB), because it uses that extra area for write operations and then performs a deletes what is has now learned is an inactive page/block.
SandForce puts a lot of marketing into their controller, and it is pretty fast, partly because it does a lot of compression of your data when it can (which worries me a little bit anyway when using it with a non-integrity checking file system like HFS+). But nearly full drives that are TRIM-compatible are going to stay quicker throughout the life of the drive, while others will not simply because they can't know as much about what they are trying to organize as an OS-based routine like TRIM will.
And you don't necessarily want to pay for space on your drive which you can't use: this means you're losing about 7% capacity on top of the 7% you need to leave free for the OS's maintenance routines (like on-the-fly defragging, which is also part of at least Apple's TRIM implementation, so it's actually more efficient to do both at the same time anyway). With TRIM enabled, you can reuse the scratch space for both tasks, since the OS can see both, but not with SandForce.
The question at this stage is, just how much more efficient is the clean-up algorithms of the SandForce chip versus OS-based TRIM?
This is mostly a marketing claim, because Sandforce is quicker at doing the easy garbage collection that it is capable of, while it's a longer route with more components involved for the OS to get the easy consolidation commands out of the way. Thus, more efficiency means slightly faster operations with only one component involved. Conversely, the SandForce controller is incapable of doing all the things that TRIM does, but I guess you could argue that doing less is also more efficient in the short-run.
Also, there are those failure rates. If you look up the Vertex 2 reviews on any site, you'll see nothing but complaints about their failure rates, enough so that OCZ listed increased reliability as a feature of the Vertex 3 (which uses a newer generation of the SandForce controller). Is your data something you want to trust to marketing promises, especially when combined with all the aforementioned data compression going on?
