If it’s a single threading issue, then Audition should divide the sessions into chunks, one thread for physical core, and render the chunks in parallel. This technique is already used for video rendering.

Matt, just because it’s not easy doesn’t mean you shouldn’t find a way. This might be a classic single versus multithreaded issue, but it’s also a classic “it’s always been done this way” response. Please, please at least leverage all cores on export. Find a way to help us maximize the investments we make not only on hardware but in Adobe as well. Otherwise, it makes much more sense for those of us that have the luxury and flexibility of looking elsewhere to do precisely that. And while I’m guessing the default attitude (based on the across the board responses I’m seeing from Adobe on this issue) is that one user is just a drop in the bucket, it does add up. Plus, performance and leverage of hardware is a long, long, long standing issue for many CC users. You did make some GPU performance strides for 2020 (not in Audition, clearly) while shoring up a lot of what made me feel like an Adobe beta tester in 2019, but there is still plenty of room left. Again, I don’t care how hard it is for you. Multicore processors have been a common thing for a decade now. All our phones have them. Our iPads have them. There is no reason I should build a test project in Premiere and watch it take 5 minutes to export while the same is 2 minutes in Final Cut and 45 seconds in Luma Fusion on iPad. If you’re not leveraging resources properly, no matter your excuses, you’re doing it wrong.

I think I understand what you are saying. This is just how Audition works. Lemme see if I can explain.
It appears that you are time stretching a 13 hour audio clip. When using the "Effects>Time and Pitch>Stretch and Pitch..." effect, the internal algorithm is a high quality stretch that looks at the audio before and after the potions that is currently being acted upon. This is an inherently linear process, the data needs to be acted upon in a linear manner. This cannot be easily broken into multiple streams of data and "multithreaded".
In your screen shot you are showing Audition use roughly %107 percent of the CPU resources of the iMac Pro. This means that Audition, when it is rendering this stretch, is maxing out a single processor thread, and maxing out a single core of the CPU in the iMac. Unless there was major engineering added to the Radius stretching algorithm, this is as fast as it can go. This is the classic dilemma about single threading vs' multithreading. If a piece of software cannot use multiple cores, it wont and it will seem like it is not using the hardware to the full potential. This is probably what you are seeing.
Audition will process multiple files in parallel, and do it well. So if you need to stretch 16 files, and your computer has 16 cores, Audition will light up all 16 cores and process the files in parallel, which is using all the hardware available to it.

What I can recommend is to use the multitrack, not in the Audition editor.
Place the file you want to stretch in the multitack, and use the realtime stretching option in the Properties panel. This is a related stretch algorithm, that is much faster (it is realtime, no rendering involved). The quality is slightly less, but you can use your ears to determine if the quality is fine or not. You will need to export the multitrack, which is still much faster than stretching a 13 hour file in the Editor.
1. Take you original clip (the 13 hour one you want to stretch), right click on it and select "Insert into Multitrack>New Multitrack Session"... Create a new multitrack on disk, leaving the Sample Rate alone and setting the bit depth to match your original material. Hit ok to create the new multitrack.
2. In the new multitrack, select the clip on the timeline. Open "Window>Properties>Stretch...".
3. Leave the mode as "reatime" but set the Monophonic or polyphonic setting as needed. Set the desired stretch amount or duration.
4. This will stretch the clip using the realtime “Omega” algorithm. You can then export the multitrack much faster.