SQL Server Database Table Partitioning Consideration
The real use case for table partitioning is fast load and unload of data.

If your warehouse tables and staging tables are in the same database, and have the same schema, you will be able to swap a partition from staging to warehouse very quickly.  Similarly, when data has reached its retention expiry date and must be purged, it is very quick to delete a whole partition of data.  This page and its ilk will give some pointers.

As each partition can be directed to a different filegroup your backup &amp; recovery cycles could be shortened at the cost of increased complexity.  For example, load one company's data, process it, then take a backup of the file(s) that hold that company.  Perhaps several companies could be processed in parallel, knowing that file contention will be reduced through partitioning?

Indexes can be partitioned as well as the tables.  Index maintenance can be performed one partition at a time.  This could reduce contention and overall load on your system.

Using partitions solely for performance enhancement can be problematic. Every query will have to have the partition key in the predicate, as a minimum.  Sometimes the optimiser chooses not to perform partition elimination even then.

Partitioning is no free lunch.  It has costs as well as benefits.  You must consider both sides and test well.  As so often in DB design "it depends."