I just took a very brief look at the code, and it seems that when rendering, you create a DispatchGroup and submit the tile-rendering jobs to the global (concurrent) dispatch queue.
The design is quite nice and straightforward, and it seems at first glance like it might not be too disruptive to port to Swift concurrency. You could add the tile-rendering jobs to a TaskGroup and merge the results as they become available, and - perhaps more interesting IMO - you could batch the rendering jobs using async let. I've heard that one of the benefits of Swift concurrency is that when a function uses async let, it has a known "amount" of structured concurrency (e.g. 8 structured child tasks), and the compiler can optimise how it allocates the stack that each child task requires, but I think you need some really heavy workloads (like this) to see the benefit.
Have you started experimenting with anything like that? If/when you do, please do post some results and don't hesitate to ask questions. I think lots of us here would be very interested to see how Swift concurrency scales in a project like this.
The tile rendering predates Swift's structured concurrency. I'd love to convert it to async let and I think it should be only a modest change. But I also have lots of other things on my plate so let's see when I get to this. It might be also a good beginner's task.
There is also the Import statement which currently only calls include at func import to (sequentially) read scene files. Import can be used to parallelize reading of huge scene files, see Matt Pharr's blog. Currently Moana takes around 17 minutes to load, I believe this can be cut down to under 2 minutes.