For the fsync rate, my memory is vague, but I think InnoDB respects the write-ahead-log rule even with innodb_flush_method = nosync and this means that before a dirty page is written back the log must be forced for any changes to that page. If you run strace you can determine which files get the fsync and if it is only the log then my memory is correct. I haven't used innodb_flush_method = nosync for a very long time (maybe 6 years ago) and when I did I hacked it (probably to not sync the redo log as suggested above). I almost always use innodb_flush_method=O_DIRECT and then configure enough background write threads.
For write amplification you are computing the rate as Innodb-write-rate / InnoDB-read-rate. But I think your InnoDB-read-rate is the scans of the PK index while the write rate includes IO for PK and secondary indexes. This is still write-amp, but deserves an asterisk to explain that point. Write-amp from the doublewrite buffer can be much cheaper than write-amp from dirty page writeback where "cheaper" means fewer seeks.
If you want to make the load go faster than creating the secondary indexes after the table has been loaded might help.
Another interesting question is whether to load in parallel or one table at a time. Sometimes, loading one table at a time helps because you are more likely to keep the working set in memory during the load. This can be very important when secondary indexes are maintained during the load as you can do too much random read - modify - write for secondary indexes, although the InnoDB change buffer helps a bit with that. The choice here isn't all parallel vs 1-at-a-time. Doing a few at a time gives some parallel benefit, but also gives each table load a better chance at keeping secondary indexes in memory during the load.
It might help to increase innodb_max_dirty_pages_pct to 90 (you used 75). I don't have current experience with it but you might also want to increase innodb_max_dirty_pages_pct_lwm. The goal is to not write back dirty pages too soon.
Making your InnoDB log files as large as possible will also help defer writing back dirty pages and reduce your page write back rate (and write-amp) in a good way.
| innodb_log_file_size | 524288000