A few things...
1. USB can present multiple drives to the OS via one cable, with an appropriate controller. Performance, of course, suffers, especially when you are reading/writing to multiple drives simultaneously. Essentially, the disk controller presents the disks to the OS as a
JBOD array. When only one drive is "talking" at a time, then it gets close-to the full bandwidth of the bus to itself (though no single spinning drive is going to fill a USB 3 bus). However, when multiple drives are "talking" at once, not only is available bus bandwidth divided, but the controller has to do a lot more work at once (and generally not in a pre-planned and optimized way). Count on lower performance for a JBOD array than you would get for a single disk on the same bus in most circumstances, and the problem generally gets worse the more drives you add to the array.
2. I have a number of Addonics storage products, and I've always been satisfied with them. My main media volume at home is built with an
Addonics Storage Tower with two
Disk Array 3SA's installed. The
only complaint I have is that the fans in them are small and loud. Don't expect to keep this in the living room, but it is fine in the server room.
Lastly, regarding RAID... RAID 0/1 is entirely about speed or data reliability. RAID 0 (striping) can provide (sometimes dramatically) increased sustained read/write speeds, and can improve random access times in some cases (if backed by a good controller). This makes sense. It is basically giving you two sets of everything involved in reading/writing and they can be used simultaneously in "concert" with one another. Plus, since the controller maps out storage in a "rational" manner, it can optimize the disk accesses so that it doesn't waste a bunch of time dealing with overhead (generally the RAID controller takes over the job of error correction and caching, for example). The downside is, of course, that if you stripe 2 disks, and one fails, then you lose the entire volume (all of the data).
RAID 1 (mirroring) is basically the opposite. It provides redundancy. If you build a two drive RAID 1 array, the two drives are kept block-by-block in sync at all times. Basically you always have two copies of the disk, so if one fails physically, the other keeps working. However, this "costs" double the storage requirements (so to have a 1 TB volume, you need two 1TB disks in the array), and it does
not protect against user-error (deleting things by accident) and filesystem corruption (which will be happily mirrored by the RAID controller). RAID 1 can also provide some limited read-speed performance enhancements, as your system can read from both drives in tandem. However, it generally slows write speeds as the controller has to do twice as much work for each write.
RAID 5 is a compromise of sorts. This allows you to combine a bunch of drives into an array and format them as one volume. Like RAID 0, it stripes the data across the drives, so you gain the performance benefits of using multiple physical disks working in tandem to service read/write requests. However, it also provides redundancy. Unlike RAID 1, where your data is duplicated block-by-block onto a second physical disk, RAID 5 calculates parity bits for each write to the volume and stripes the parity bit data across the array along with the actual data. This means, essentially, if one of your four drives dies, you don't lose any data, as the controller can "rebuild" the lost stripes using this parity information. So, it gains you most of the magic of RAID 0 without as much risk (two separate drives in the array would have to fail simultaneously to cause the entire volume to go belly-up). RAID 5's write-performance benefits are somewhat limited by the need to calculate the parity information for every write. Many more expensive RAID controllers include a hardware RISC CPU (often ARM-based anymore) that does this parity bit calculation. Cheaper software based RAID systems do the calculation on the system's CPU. This used to be more important in the days before modern multi-core CPUs, though hardware implementations will still typically outperform software-only RAID in writes (especially random writes).
There are other RAID levels which are modifications to these basic principles, including RAID 6 which provides multiple "tiers" of parity (allowing two or more simultaneous drive failures at the cost of additional "wasted" space used by the parity information). Again, though, this only protects against physical drive failures. RAID is not a backup.
RAID 5/6 can be very convenient for building large volumes. It is a way to attach multiple drives to a system and mount them as "one big volume" and to allow the drive controller to use them together in a much more efficient manner than JBOD (just-a-bunch-of-disks). There are downsides, though. The biggest one is that each drive in the array must be, essentially, of the same size. RAID can only use "similar" drives. If you install 2 1TB drives and 1 2TB drive in a RAID5 array, then only 1/2 of the 2TB drive gets used. Similarly, the performance of the array is limited by the slowest disk in the array (since all reads/writes are striped across all of the disks, basically every read/write will "touch" the slow disk). Lastly, in most cases, it is difficult to add capacity to an existing RAID volume over time (though good controllers do support online capacity expansion). With a cheap controller or your average Intel motherboard software RAID, you have to nuke the whole array to make any changes to it. However, if you want to build a Really Big Volume, and you don't want it to be (a) slow and (b) vulnerable to a flaky drive failing, then RAID is your best bet.
Systems like Drobo, unRAID, and BeyondRAID are software-based systems that aim to eliminate most of the "problems" with RAID5/6 (using dissimilar drives, online expansion, increasing redundancy). Mostly they are very good at solving those problems and providing redundancy. Mostly, they are also substantially
slower-than just using a regular standalone disk, much less a high-performance RAID 5 array. However, they allow you to do things like slap in 1 750GB drive, 3 1TB drives, 2 2TB drives, and so on, and not lose a substantial amount of the storage capacity to waste (though redundancy usage is usually higher in these than it would be on a "straight" RAID 5 system). They are also typically easy to expand without reformatting.
My main media drive (in the above-referenced Addonics boxes) is a RAID 5 array that is backed up rigorously. It is wonderful and I have absolutely no complaints. The convenience of having only one volume (M:) to deal with is my primary motivating factor, but I wouldn't want to risk doing that without the redundancy of RAID 5. Disks do fail. In the six or seven years or so that I've been running RAID 5 in various incarnations, I've had 4 disks fail. If I'd been using a "riskier" array (especially JBOD), I almost certainly would have lost some data at each of these events. And, it is very fast. Much faster (particularly at reads) than any one of the drives would have been alone. I can use it to store things where performance actually matters (like VM images) and use it directly as a recording drive for my DVR activities when needed (writing 3 simultaneous 1080p videos to disk is no simple task,
especially if you might be also watching a fourth video upstairs on the HTPC).
Again, though, I can't stress enough... RAID is not a backup. It protects against physical failures, which is one class of problem (and that is good), but it doesn't protect against other issues like:
1. Accidentally deleting files (in fact, this can be exacerbated by the RAID 5 striping which can make data recovery more difficult/expensive).
2. Fire/Flood/Natural Disaster
3. Filesystem corruption. RAID happens at the block level. If the files-themselves are being corrupted by the OS "up the chain" (something that chkdsk can't repair, for example), then your parity information is useless because it just "protects" the bad data.