Tempdb log growth 3x as slow on new server, SP does not perform
While determining why the growth is taking longer on the new server is a task that can depend a lot o your environment, as noted by David Spillett's comment, it's likely that you might have sized the tempdb in a way that is not optimal for your server, causing auto growth to be triggered frequently.
As Brent Ozar says on his Cheat Sheet: How to Configure TempDB for Microsoft SQL Server:

configure one volume/drive for TempDB. Divide the total space by 9,
and that’s your size number. Create 8 equally sized data files and one
log file, each that size. Presto, the drive is full and your TempDB is
configured for easy performance.

Sizing tempdb properly is also listed on the Optimizing tempdb performance in SQL Server doc as a good practice:

Preallocate space for all tempdb files by setting the file size to a
value large enough to accommodate the typical workload in the
environment. Preallocation prevents tempdb from expanding too often,
which affects performance. The tempdb database should be set to
autogrow to increase disk space for unplanned exceptions.

Finally, if your new server has more than 64 CPUs, the doc on Best Practices for running SQL Server on computers that have more than 64 CPUs says:

Do not rely on autogrow to increase the size of the transaction log
file. Increasing the transaction log must be a serial process.
Extending the log can prevent transaction write operations from
proceeding until the log extension is finished. Instead, preallocate
space for the log files by setting the file size to a value large
enough to support the typical workload in the environment.

Considering mainly the point about preventing transaction write operations, if the SP that is not performing does any write operation, it would be affected by the autogrow.
So, even though this advice does not answer your question about the reason the growth is taking longer to be performed, I thought it was worth mentioning it.