No, it it's not possible to restore a database from an ldf file. The ldf file would be restored along with the mdf files.
No, it's not redundant as they have two different purposes.
It's important to take full backups, and transaction log backups. Only having a copy of the ldf file doesn't help you restore the database.
As to what a ldf file is for, the ldf is the transaction log. Think of it as a circular buffer that records changes to your database. When you update a row, the change is immediately written to the ldf. At some point in the future (usually less than five minutes), the modified data is written to the mdf file.
If the server crashed or there was a power failure, when SQL starts, it reads the ldf and re-applies (REDO) those changes.
Additionally, if you have a transaction that hasn't been commited and the sever crashes, all changes made by that transaction have to be undone to make the database consistent. The ldf file has that task as well. (UNDO)
I mentioned above that the ldf file is circular. Taking a transaction log backup (.trn) copies out a portion of the ldf file. After a trn file is safely created, sql can reuse that portion of the ldf file. The series of trn backups create a chain that together record every modification made to the database. Of course, if you never took a tranaction log backup, the ldf file would grow and grow and grow.
In a disaster scenario, restoring the full backup gets you a copy of the database as of the time the full backup finished. You can then restore the trn files in order and bring the database current to any point in time including up to the last trn backup.
I'm glossing over some important details, but the gist is the that ldf is a working file that records recent changes to the database. The trn files are copies of parts of the ldf made under the assumption that you will keep then safe so that sql can reuse the space in the ldf and if disaster strikes, you'll have them in an alternate location.
If you have a single RAID10 volume then as far as SQL Server is concerned you have one volume and you can't control how things are stored, splitting things into extra files unnecessarily will likely have detrimental effects as it would on a single disk.
If you wish to try gain performance benefits from segregating data between spindles then you need to split the drives into separate RAID arrays, perhaps four in R10 for data and two in R1 for logs, or three R1s for everything, data and logs spread over the three.
Unfortunately there is no fixed wisdom here, it will vary greatly depending on your application's I/O loads. Splitting data and logs makes little difference for many load patterns (though can make a massive difference for certain write heavy loads) for instance. The only general advice that is applicable without a lot more detail about the application is "bung it all on that volume on one file/data and one/logs and trust the I/O scheduler to be fairly bright".
Best Answer
Well, you shouldn't encounter any errors from SQL Server, if that is what you are asking about. SQL Server doesn't care where the files are located. That being said, there are good reasons for having different file types on different drives.
Performance - Having different files on different drives means that there are different sets of drive heads reading the data. Your throughput for simultaneous read/write operations goes up. Especially if you are backing up to the same drive that your data files are on, this will suck.
Maintenance - What happens when your drive fills up because the part of your script that cleans out old backups has failed and now your drive is full? If you had separate drives then just the one then your damage would be limited.
What happens to your backups when your primary drive fails? Are they being taken off to tape somewhere else?
If this is a production server then I strongly encourage you to separate out to at least separate Data and Log drives and backup to a different machine.