Does innodb guarantee unique data in unique indexes even with UNIQUE_CHECKS=0?
Normally, index changes are put into the "change buffer" for later writing to disk.  This happens for non-unique indexes.  (This also applies to UPDATEs that change a UNIQUE index, and DELETEs, which necessarily remove a 'row' from the index.)

For UNIQUE indexes (and UNIQUE_CHECKS=1), each row being inserted is immediately verified as not being a dup.  That way, the row can be rejected quickly.  The drawback is that it must fetch the index block that contains the value in question.  For huge tables, this may involve a read from disk, which can be relatively slow.  And that disk read is blocking, so the INSERT must wait.

For a batch load of rows, it would be faster to load all the rows, populate the change buffer, and postpone having to actually look at the disk index.

UNIQUE_CHECKS was implemented in the days before fast SSDs and when RAM was small.  That is, it used to be an important optimization.

The "Change Buffer" is a portion of the buffer_pool (default: 25%).  It holds secondary index changes awaiting consolidation and insertion into the disk copy of the index.

When an index lookup is needed, it must check both the change buffer and the real index.

The real index is a bunch of 16KB blocks in a B+Tree organization based on the secondary index.  Those blocks are cached (one-by-one, as needed) in the other 75% of the buffer_pool.

With UNIQUE_CHECKS=ON, the uniqueness test can be immediate; with it off, I suspect that the test is not done until either the bulk INSERT is finished, or the change buffer needs some flushing.

The change buffer is written to disk in the background.  Note:  This is one explanation for I/O when no queries are running.  Logically, the CB is sorted; a block from disk is read; entries are merged into that block; then the block is left in the buffer_pool as "dirty".  Eventually, another thread worries about writing dirty blocks to disk (another cause for strange I/O).