Tablespace Fragmentation depends on OS fragmentation so itīs not really an issue here, I think i wouldnt care about database fragmentation anymore for those tables which wont be scanned fully for a query.
Seperating indexes and data in Raid 0+1... I dont see much point in perfomance issue except that itīs probably easier to administer otherwise we could just have everything in one tablespace (everything!) :D
Placing tables and indexes in seperate tablespaces will reduce I/O contention and thus result in better performance regardless of the RAID level. Index and Data tablespaces typically reside on different mount points. These mount points are groups of physical disks. Yes, if you place a datafile on a 0+1 device, it will be stiped across x number of disks. However, if you put a datafile for the data tablespace on one set of 0+1 disk and your index tablespace datafile on another set of 0+1 disk, you have two sets of disks spinning during a query instead of just one. In an ideal world, these to filesystems would be controlled by two different disk controllers.
0+1 is just a disk technology. As a DBA you must always think of disk resource as a single disk to eliminate I/O contention. In this situation you have to ask yourself, "Would I put my data and indexes on this disk if it were a single 9G 5400RPM drive?"