Strange that the WD blacks do not work in Raid0 as I've beeing using them since I put my E6400 together (about 2 years).
On strip size vs cluster size, There were several discussions on on that topic (Google strip size for Raid0). For boot drive + programs I think the general trend was toward the smaller size (Over half of files are under 16K). If looking at performance, google "Short Stroke" - you gain performance, but lose space.
WD Blacks do not have TLER so any bad sectors arising from BER (Bit Error Rate) would cause that disk to be disconnected/dropped from the array. This problem is very widespread and basically happens with all hardware and windows software RAIDs.
As i understand, the basic root of the problem is RAID engines not being able to distinguish a failed disk from a disk that is performing error recovery and thus times out its read request. The RAID engine would assume the disk is failed and drops the disk from the RAID. As long as you don't encounter bad sectors (Current Pending Sector (C5) in SMART output) you shouldn't have this problem. non-Windows software RAID is not affected by this problem; and thus can use 'cheap' disks in RAID without cause for alarm. It is hardware RAID and onboard Windows RAID which would need TLER to prevent array splits.
Also WD Black's would develop bad sectors due to BER 10 times more often than the 5400rpm versions, if you believe the specs. Strangely, the firmware-enhanced RAID editions get the same spec as 5400rpm disks; which i seriously question as the disks are not physically different and only differ in programmed firmware; to earn some extra money from customers paying for the TLER feature and longer warranty period.
And perhaps another misconception: many people seem to believe smaller stripesizes are good for small files, and large stripes are good for large files. My tests indicate the exact opposite. And it makes sense: better for both disks to handle a completely different file than for each disk to transfer a chunk of the same file, but requiring both to seek to the same file.
As such, stripesizes of 4 megabytes proved very good for random I/O, but were too high for sequential I/O to saturate all the disks. Thus here a large stripesize was excellent for random I/O but poor for sequential I/O.
I do have to to add these tests are on FreeBSD. Windows onboard drivers are less sophisticated. Some even transfer the whole stripesize even if a fraction was requested; a low-level tweak or optimization used for enhance HDtune benchmarks but having bad real-world performance effects.
If you want to review the benchmark results, they are on my site (geom_stripe benchmarks).