I tend to agree. RAID 1 is fine for your desktop where you don't want to waste time restoring your backup when a drive inevitably dies. When the kernel gets confused and says both drives are corrupted simultaneously, it's easy to manually repair with dd. (See which block has unrecoverable errors and copy that one over from your other drive. Repaired. Not sure why the kernel can't do this automatically. The data is gone, you can't make it worse.)
For datacenter applications, having everything on one machine behind a filesystem abstraction seems like unnecessary complexity, not to mention a single point of failure and a waste of resources. I'd much rather handle things on the application level; if I want three copies of my data around, write it to three different machines with disks. When a copy seems unavailable, make an extra to keep the redundancy level the same across disk failures. If I want some redundancy encoding, just store that instead of the raw file. Now there is no complicated recovery when your disk fails. The system is always in a recovered state because disk failures are expected and uneventful.
That said, there is a bit of complexity in implementing this, and even more complexity when you want all the pleasantries of a UNIX filesystem (permissions, quota, etc.). I know of only one working implementation of this technique, and it's not open source. And, of course, if you're going to use existing software rather than writing your own, you're going to need a UNIX filesystem for it to use, not some clever chunk storage manager you wrote. So btrfs and zfs persist.