Sigh. No one forgot or failed to know about it. In fact, that comment was made in regard to comments by myself and Matt who created it. It’s just another dishonest smear. (particularly given that the comment it was initially made in response to was my PR comment which expressly discusses the subject!)
The extrapool was primarily created for replacements. It’s applicability to heterogeneous policy is relatively limited, particularly when the subject being discussed-- as it has been here-- is Bitcoin Core’s defaults.
Extrapool and extrapool like techniques only help when you’ve observed, downloaded, and processed a transaction – that is the case when you are an unusual node filtering more than others around you. But in the case of Bitcoin Core’s default relay policy it won’t help because generally you won’t have ever seen the transaction to begin with.
Like many other things in the p2p protocol there are assumptions that the behavior of honest nodes is pretty homogeneous (and consistent with mining). Where you know its not it would be useful to increase the size of the extrapool, though increasing it isn’t free because both the worst case memory requirements and a slowdown in processing blocks due to the additional conversion/matching. The increase also undermines one of the arguments people are making for the filtering in general-- that it at least keeps the transactions from wasting their memory until they’re mined.
Improvements may well be useful, I think it likely (and I previously advocated for them!)-- but none the less have no relevance to Bitcoin Core default policy discussions for the aforementioned “you can’t extrapool it if you never saw it” reason.