Apologies for the delay. I get several hundred emails a day and I occasionally miss a couple.
Because of the variances in the size and static nature of each of your tables and the fact that you have an eligible partitioning key in the "LKey" column, it would really be nice if MS allowed for a "duplicate partitioning key" consisting of the LKey and the Create_Date of any given row, perhaps by month. The advantage there would be that you could easily move or delete an entire company if the need should ever arise and, since your queries sound like they're usually based on one given company at a time, it may also help you with reducing query contention. Not sure it'll help with reducing server core usage, though.
Of course, partitioning is relatively a PITA, especially if something goes haywire. Further, proper indexing can save you a lot when it comes to reducing contention although you do need good code for that to happen. So far and though a lot of folks have made claims to the contrary, I've not yet seen any examples of partitioning that have actually sped code up. I've beaten a couple of such claims just by following good coding and indexing practices.
To get to your final point, there certainly ARE some HUGE advantages to adding, for example, a non-clustered index that's identical to the clustered index especially on wide tables and especially if the index covers what you need to retrieve. But that doesn't matter if the table is partitioned or not.
My bottom line on partitioning is that you should never partition for performance because it's not worth it. Partition to make maintenance and rolling off old data and, perhaps, importing large quantities of data. The latter 2 of those notion are the reasons why indexes need to be aligned.