Clustered Index with nightly ETL process
There are few ways to work around this problem:

As you mention, partitioning will help. If you partition on the leading column in the index and make sure all partitions are equally sized, you can gain super scale. However, the total CPU required to build the index wont be much lower if you partition. But it will save you memory (if you have a slow I/O system, this can be useful)

If this is a traditional data warehouse fact table, you might be better off with a columnstore index

Instead of doing a mega update - which is slow. Consider this pattern: 


Load the changes you want to make into a staging table with the same schema and cluster index as the main table
Join the staging table with the old table and use INSERT INTO a new table with a cluster index. Enabled Trace Flag 610 while doing this.


This way, you can keep the benefit of the old table being sorted and avoid resorting all the rows (only the ones that have changed).