Core devs value the idea that mempools should be able to predict what transactions are going to be in blocks in order to prevent unnecessary transaction data requests among nodes.
The other technical argument on the Core side is that it's useless to maintain a filter that can be bypassed.
And why is it more predictable?
It's more predictable because transactions that are filtered don't have to be requested again. To this I would respond that they can simply be cached
Ok, but this is more a bandwidth issue you are referring to, isn’t it?
When it comes to more predictable fees my understanding is that this is because those who want to propagate this type of transaction have to find workarounds to get this transactions into a block because of the filter as it is right now. This means that it slows down this kind of transactions which is the purpose of filters, like calle explained before.
Yes my point was all about bandwidth and compact block relay to be more specific.
I agree with you that filters, if widely adopted, make certain kinds of transactions harder to relay, meaning that parties relying on those transactions being mined according to their temporal preferences cannot build protocols that take advantage of them being mined.
This unfortunately means that these parties will find other ways to accomplish their goal of getting their transactions mined in time, i.e. instead of using OP_RETURN they will embed data in the witness section of the transaction.
