Поможет ли суррогатный ключ увеличить скорость вставки в таблицу?
Если речь про Innodb, то
 Indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.

If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key. 
https://dev.mysql.com/doc/refman/5.7/en/innodb-ind...

В вольном переводе каждый из ваших вторичных индексов будет содержать в себе значение из primary key (PK) и чем длиннее PK, тем больше все индексы в таблице.
Вполне вероятно, что при таких раскладах PK даже из 8 байтового bigint сильно выиграет у 36 байтового char+int (а то и 102, если с дуру сделали ID utf8mb4). Как минимум по занимаемому месту.
Сделал ещё ряд тестов.

Точно так же, две таблицы:
- первичный ключ: char(32)+date, партицирование по годам + 3 дополнительных индекса по полям;
- первичный ключ: auto increment+date, партицирование по годам, уникальный ключ char32+date + 3 дополнительных индекса по полям;

В каждой таблице изначально 5 млн строк, в каждом тесте вставлялось по 100 000 новых.
Строки вставлялись по одной и пачками по 20 (среднее кол-во на продакшене за один вызов скрипта).
Запросы делались по одному, без оборачивания в транзакцию (насколько я понимаю, если запрос один - то и транзакция бесполезна, независимо от кол-ва строк?).

В результате получено ускорение в 2,6 раз:
- 0,010 сек с суррогатным и 0,026 сек с char(32) построчно;
- 0,003 и 0,007 по 20 строк за запрос.

Кроме этого, batch-запросы с auto increment имеют намного меньшее max время вставки: 1,5 сек против 11,4 (да, 11 секунд на вставку 20 строк). 

Также при заполнении таблиц тестовыми данными (5 млн строк на каждую), auto increment показал в ~2.3 раза больше скорость и в целом скорость держалась +- стабильной, когда как для первичного char(32) ключа она постоянно падала вместе с заполнением таблицы.

В целом можно сказать, что да, суррогатный первичный ключ действительно сильно ускоряет вставку по сравнению с char(32).