Worse case scenario, couldn't I run something like "cat /dev/zero > nullfile && rm nullfile" every once in a while to zero out every unused byte? The only problem is remembering to run that periodically and when I'm not in the middle of something.
Don't do that with a SSD, that is not what TRIM does at all! The NAND cells that contain bits can only be in two states, written to (contain data) and ready to be written to (erased.) The contents of a NAND cell does not determine if it contains data or is erased (in the erased state, if a cell was read, it contains a '1') since NAND can only be erased at the Block level. A flag bit is used to indicate a fully erased Block, or an in use Block with one or more pages written (even if it is not full of data.)
NAND must be erased before it can be written, it must be in the ready to be written to state. Current file systems designed for HDDs (which can simply over-write old data) don't tell a drive that data was deleted, it just puts the block addresses that were used by a "deleted" file into the free block list.
TRIM was created to cater to the necessities of NAND storage with file sysems written for HDDs. TRIM instructions contain the page/block addresses of deleted data. The SSD controller uses that information to erase no longer needed data, so the NAND storage can be in the ready to be written to state. It takes longer for a SSD controller to erase NAND and then write to it, than to simply write to it (already in the ready to write state.) Actually, erasing NAND is the slowest operation performed on it. If that can be done ahead of time (during a SSDs 'garbage collection" function) or on demand, the SSD will perform better.
That is why writing anything to NAND storage does not clear it, it really makes it worse. Even if you wrote '1', the default/erased state of a NAND bit, to the entire SSD, all the bits are in the written to state, and must be erased before being written to again.
TRIM is not simple to support in RAID arrays, since the OS/file system has no idea where the data is really stored on the RAID volume. The RAID software would need to translate what data can be erased according to TRIM, into how it is mapped in the RAID volume. Easier said than done!
Sean and others are steering you away from RAID volumes of multiple SSDs, because the high speeds seen in benchmarks of 1,000MB/s reads for example, is not how fast a SSD works all the time. That is for very large files only. Small 4K - 16K files, which are more common, and what make up a good percentage of an OS, are read at 20 - 35MB/s by SSDs (HDDs read less than 1MB/s on those files.) RAID 0 does not increase the small file read speeds at all, and usually decreases it, as seen in benchmarks.
OTOH, as a user of SSDs in RAID 0, IMO the benchmark programs are not telling the full story. IMO, RAID 0 volumes of SSDs can be faster than a single SSD. Not automatically, but they can be. FWIW, I have a RAID 0 volume of four 64GB Samsung SSDs, running as the OS volume, for over a year and it works fine.
AMD RAID faster than Intel RAID? Not from what I have seen...
Stressing the SATA ports? If it is designed with 10 ports, how does using half of them stress it? Maybe it does, but I'm an Intel user, with six ports max.