Thank you for a thoughtful suggestion and your perspective on the subject. I’ll address every section separately below.
$103,000 at 7% interest results in about $600 a week. To claim and re-stake weekly results in 8% cost + taxable events ($50 combined estimate for 2 transactions.) Because of this, there is a market for automation.
Completely agree with you on this - both gas fees and tax could be optimized by aggregating capital and automating the process. I believe it is our job as a development team to approach relevant projects regarding the automation, but also to give them something to work with i.e. strategies or suggestions about the precise changes they could make into existing contracts to build something for us.
This brings me to your other point:
We offered, if they refuse we do what we need to do. By doing in house automation we would get to outline the parameters, we would be able to offer users the opportunity to not farm and dump.
Again, fully agree with this approach. In the ideal world, automation of farming strategies would pop up immediately based on the opportunities to make a quick buck from it, but admittedly, the current state of things is far from ideal. So we’d want to do some prodding, and if we must rest our case with integrations, we will want to squeeze out every bit of value from doing this ourselves. That’s something that requires more time and thought from the team, but we are aware of that.
Is there a way to alter the contract rETH2 waits to be claimed in to also accrue SWISE rewards relative to the users share of total rETH2 in the contact per unit time? Or, what about deploying another contract that calculates user share of unclaimed rETH2 and have a claim rETH2 button and a claim rETH2 & SWISE button. Separating complexity of the transaction and putting gas costs on the user, but also including them in the SWISE incentives.
The current thinking and approach is precisely one of gas optimization. Automation would still need to be based on the process of claiming rETH2, $SWISE and others, so having a strong foundation is a must.
The way we see it at the moment is that users should be able to decide when to pull rETH2 and/or $SWISE from gauges/contracts, and let them preserve anything that their capital accrues until the moment they’re ready to pull the trigger. Also, we want to make claims efficient, so that with one light transaction, a user could pull multiple tokens at once. The ‘novel rETH2 distribution method’ listed in the pipeline aims to achieve precisely that.
On your last point:
Would it require deploying new contracts, would that be able to be a one time thing, and are either of these less gas intensive than the vaults mentioned in the original post?
Vaults by definition will be much more gas-efficient, but that doesn’t mean we shouldn’t work on making the farming & claims process as gas efficient as possible. These go hand in hand 
Awesome discussion here guys - thank you @George and @Sebastian_Bach. I am looking forward to hearing more thoughts on the matter from others!