Reclaim disk space from large database's primary filegroup after truncating tables (other than shrink)
Community wiki answer:

It's going to take some time for the shrink operations on such large database files to run. Honestly, you should consider running the DBCC command and just letting it run as long as you can, on days and at times you can afford. Just let it do it's thing.

If the shrink operation is stopped before completion it does not roll back the changes so even if it runs for 2 hours on one day, another day for 4 hours, and so forth until a weekend or something where you can let it run a whole day until it's able to complete quickly.

Run scripts to check DB free space before and after each run too.

This way no exporting to new DB structure or whatever, and you can just let it do it's own thing. Do some more research, but in similar-sounding cases, I've been involved in the past (huge data warehouses where data loaders did things all wrong - using the actual DB for temp tables rather than tempdb), it happened and was what it was. I got the issues tracked down, retrained data loaders, and then did the cleanup. Afterwards I worked on taking care of fragmentation, etc. where space was higher priority than performance.

Because of the issues mentioned, we have always shrunk files in smaller chunks. In my experience, the shrinks are excruciatingly slow initially, i guess because SQL Server has to move the pages from the end of the file before shrinking. But as you progress it becomes faster and faster.