This is not unique to Microsoft products. Databases have been doing this for a long time. Oracle Database has options for RAW devices and disk access, where redundancy is handled in the application layer by throwing more disks at the problem. You can also stack your layers of redundancy by using Oracle automated storage management to have multiple logical disks while at the same time using an array controller to provide a level of RAID redundancy at the physical layer.
And a point about JBOD being useful for Exchange. In most Exchange environments I have worked with, replication happens at the appication layer, with huge portions of the data store being replicated amongst members of the Exchange Cluster, each with their own copy of the data. While expensive RAID/physical redundancy is a good idea, it is not critical as exact copies of the data store are available elsewhere in the cluster, and mailboxes can be failed over to those members.
And for the people that want a full RDBMS or SQL Server under the hood of Exchange - this is primarily a performance concern. Exchange access to data stores has such a unique profile that ca be modeled to show specific performance profiles that would benefit from a customized data access layer, overall Exchange performance would be hampered by the inclusion of an RDBMS that was designed to respond to a multitude of performance profiles. When you have the luxury of understanding how your application accesses data, it is best to choose (or develop) the data storage subsystem that will reap you the best performance. Here is where I believe Microsoft has the right approach.