auto-incrementing key in self-referencing table, performance
In indexes, DESC is ignored.  (This will be rectified in version 8.0.)
MySQL is happy to use an ASC index (that is, any index) but scan it in descending order.
So DROP that redundant UNIQUE index.


That said, I don't see that anything you have described so far could be cause "excruciatingly slow" inserts.

To further elaborate.  You have 2 BTrees:


One with all the columns, and ordered (ASC) by ID
One with just ID and ordered (ASC) by it.


When inserting a new row (without explicitly specifying ID), the server is optimized to insert it into the "last" block of the BTree and bumping the A_I value.

Meanwhile, the UNIQUE index is acting much the same.  But it is doubling the amount of work to do, with no benefit.

On the other hand, if you have multiple connections doing the inserts, this may be worth noting -- How the inset works:


Get a new A_I value (well optimized)
Check all UNIQUE indexes for duplicates.  This may be slow, since another connection may be locking the adjacent ID.
Insert the row
Throw info into the "Change buffer" for later updating of non-unique indexes.  (This does not apply.)


Also worth noting in InnoDB:


Each transaction has some overhead -- writing to the undo log, writing the "double write" buffer, etc.
Hence, batched insert run much faster because they spread out this overhead over multiple rows.  Can you insert, say, 100 rows in a single INSERT?  That may literally run 10 times as fast.


Do you really need BIGINT?  It takes 8 bytes.  INT UNSIGNED takes only 4 bytes, and allows 4 billion values.