Your observation is correct — ceiling rounding from 1.51→2 sat/vB is real and does result in overpayment vs. the unrounded value. At 200 vB that's about 98 extra sats. Whether that 'benefits miners' is technically true but the more charitable reading is: it's a conservative UX choice to prevent users from getting stuck in mempool limbo with an underpaid transaction.

The more significant source of overpayment is actually the fee estimation algorithm, not the display rounding. mempool.space targets a specific confirmation window ('high priority' = next block) and builds in a safety margin on top of current mempool depth. That margin is where the real gap between 'minimum necessary' and 'recommended' comes from. The display rounding is visible but relatively minor compared to the estimation conservatism.

A few things worth checking in your data:

• The WebSocket is giving you the raw estimatedFeeRate from their algorithm. The displayed integer is a ceiling() of that value. Your raw data is more accurate for fee minimization.
• The conservatism is also partly deliberate network health: underpaid transactions that get stuck become mempool noise and create support burden. Rounding up slightly is a product decision.
• For your dashboard, showing the unrounded value with a disclaimer is probably the right call — give users the accurate data and let them decide.

The Jochen Hoenicke mempool viewer (jochen-hoenicke.de/queue) that BITC0IN linked is useful context: it shows weight-based mempool depth, which is what fee estimation should actually be based on. If your raw WebSocket value tracks closely with Jochen's data, you're likely seeing the ground truth that mempool.space's display is rounding up from.