Jochen very specifically only includes unconfirmed transactions while earn includes both confirmed and unconfirmed transactions in each of their relevant time periods. Those websites give very different information.
The earn.com website also is only showing unconfirmed transactions in the higher (green bars). The discrepancy between this and what Jochen shows and what is getting included in blocks is what I'm pointing out. The legend above could be clearer as to what the two bars are:
https://i.snag.gy/FSAYyn.jpg"Unconfirmed transactions / Transactions today" makes sense but "# OF TRANSACTIONS IN MEMPOOL IN LAST 336 HOURS" is misleading. If it was really that then the number would HAVE to be much higher than "Transaction Today". They just mean their mempool has a 336hr expiry on unconfirmed transactions.
If I broadcast a valid transaction with a transaction fee of 350 sat/byte, my transaction will remain on Jochen until the following block when, as of now, it is almost certain to get confirmed, while it will remain on earn for two weeks.
No, it will move from the higher bar to the lower bar as it is now confirmed. If you don't believe me then spend some time watching it and see what happens after a block is found.
Also, just because the miners cannot find sufficient transactions to fill up a block in its entirety does not mean there are no remaining paying transactions out there. If a transaction will have a cost to the miner in the risk that including that additional transaction will incrementally increase the risk the block getting orphaned is greater than the transaction fee (both within the transaction, and out of band), then the transaction will not confirm, even if there are no other paying transactions.
That's the heart of the issue here. Every node on the network has its own version of the mempool. In order to make a realistic fee estimation it would be logical to try and have a mempool as similar to the ones the mining pools are using as possible. The fact the earn.com's mempool contains many more transactions than the mining pools mempools is causing them to overestimate fees.
The -mempoolexpiry parameter is the only explanation I can come up with, but I'd like to hear from anyone who has another possible technical explanation for the discrepancy.