Tempdb size strategy
Based on the additional details provided, I would recommend using staging tables versus temporary tables.

The benefits are:


If there is an error, you can view the data as it was mid process for troubleshooting more easily. You can also more easily control the existence/deletion data (in regards to GDPR) rather than it being in the sometimes nebulous tempdb. 
You can simplify the code by utilizing persistent tables and just truncating them after each successful processing.
You won't be thrashing your tempdb and possibly affecting other things relying on the tempdb at the same time. 
As Jonathon mentioned, it gives you a more stable tempdb size that isn't inflated just because of a 1x a week process. 
The schema more clearly illustrates how the data is used, instead of doing a lot of data processing under the veil of tempdb. This is more of a personal preference, but I think it would be more clear for future maintenance / maintainers.
I can't think of any huge downsides to this approach, unless you have way better disks for tempdb and will suffer by using the drives for a normal database. 


Downsides provided by David Browne:


"The downsides are that writing to user databases generates more IO, as Tempdb is allowed to not flush tables and log records to guarantee recoverability. And this is exacerbated if your database is in Full recovery, and further if using an AG"


If you go this route, a common choice is to also segregate the data to a separate staging database altogether, which might help mitigate some of the negatives as this wouldn't have to be in an AG or in Full recovery mode necessarily.