other miners who don't have that set ready would likely reach a new set of "best" combination before you do, because you added extra steps to the process, besides, new transactions keep coming in every second so you are always going to be rotating transactions, so preparing anything before hand is unlikely going to work, and again, given that most bitcoin transactions have the same size, a cutting edge method to chose transactions isn't really needed, maybe at some point in the future as you mentioned.
I understand where you're coming from. But I'm wondering if there are any benefits to running a solver after having a solution given by getblocktemplate; concurrently, we can solve for a better solution while it is running. Hence, the tradeoff is minimal, if you get a better solution from your lp, then use it. Else, just use whatever is provided by getblocktemplate.
Part of my interest is also seeking to narrow the search space. I understand the entire mempool is far too big, but considering the tip of the mempool might have a slower rate of growth, which means we don't have to run a solver too often. Since considering less fee rate transactions would most likely not yield a better maxima. Also, the need of implementing it is definitely far from necessary, since difference is likely to be negligible.
Interestingly, while searching to see the discrepancy between mining pools and GBT, I found this site by 0xb10c:
https://miningpool.observer/template-and-block. It definitely doesn't tell the full story due to a myriad of factors affecting the selection of transactions but some of the pools are definitely selecting transactions themselves: F2Pool has an average of 99.95% compared to the rest which averages around 99.85% with regards to total capacity.