but I meant another issue (already mentioned by @gmaxwell if I remember correctly): Only the big miners/pools will have significant extra income due to Slipstream-style bribing. Thus the big pools offering such services will be able to increase their advantage over small pools and solo miners.
In the broader context, virtually no one mines BTC entirely solo anymore. Solo miners now use solo mining pools like CK and ViaBTC. These pools are well-connected and have excellent propagation capabilities, so I don't think we need to worry about "mining pools." In fact, mining pools must be well-connected not just to fetch those transactions but to avoid losing entire blocks.
Again, even for the few solo gamblers out there, they only hit a block once in a blue moon--almost never--so we shouldn't include them in the equation.
As for direct reach to miners, this is an "extra" service that some pools provide while others don't, and it's really independent of pool size. ViaBTC, for example, offers transaction acceleration for non-RBF transactions (the reason I stopped using them was because they failed to explain where the money goes), while other much larger pools don't do that--probably for the same reason. Once you start including transactions that are not in the "default" getblocktemplate, you have no way to prove to your users that you're not ripping them off.
So, the majority of those spam transactions (similar to the current situation of purged transactions) will have to face their fate until they find their way into a block, and all pools have almost equal opportunity to reach wallets and app wallets that first propagate those transactions.
Furthermore, the whole concept of "small miners" simply doesn't exist in any meaningful scale anymore. 80% of blocks are mined by only six pools, and 90% of blocks are mined by the top nine pools. None of these are small, and we certainly shouldn't be worrying about them--at least, not more than we have to worry about the little guy running his node on limited bandwidth who can't afford to be relaying all those transactions.
As for Ocean, last I checked, I believe they were using the Knots template, which filters out inscriptions and limits OP_RETURN data to 42 bytes. I believe the reasoning behind 42 bytes is that it should fit data commitments, which are 32 bytes. Not sure what the remaining 10 is for--maybe for a 10-byte identifier or just a random number Luke pulled while reading the Bible, which he inscribed into the very blockchain he's now trying to keep clean.
Obviously, this method, while effective, isn't perfect since:
1-It could filter other "legit transactions."
2-Some spam can still make it in.
But in general, it does the job.