Redo logs are written in sequential manner. The data files are written in random manner.
Each hard disk drive works best when writting sequentially and at this time it may reach full bandwidth (say 100 MB/s), because then it does not need to seek (re-position its magnetic head to another track and wait for the track to revolve to the proper place). When it needs to seek, a single HDD may become limited to, say, 200 seeks per second. So if you write 8 kB and then seek to another place, you would get from the same drive 1.56 MB/s (this is 200*8). In both cases drive would be 100% busy, but with obvious difference of throughput (200 vs 1.56). For RAID0 multiple drives statistically provide, say, n*200 seeks per second.
This does not pertain to SSD, in that case seek is almost immediate.
For the initial period, your data files are not written too much, because all the inserts go into the database cache. Redo log is always written immediately, without (much) buffering, it is fast, it is sequential. There is nothing wrong with redo log. After some time, you simply run out of the free cache and the db writer tries to free some cache by writing to the datafiles. If you would insert into simply one table in one tablespace, the datafile would be probably written sequentially or semi-sequentially.
So why the random operation? Well probably you have something extra in the database, such as: indexes, partitions, audit, other tables, etc. All these contribute to randomization.
It would be beneficial to separate every sequential operation to happen on a different set of physical hard drives, and to put all the random operation yet another set of physical drives. Otherwise sequential performance would suffer terribly. In your case, it is not ok, performance wise, to have redo files on the same physical hard drives as data files.
For any more information, it would be best to examine Automatic Workload Repository (AWR) snapshots (these are simple text reports).