You need both for a robust system. Simple example: On system startup, a system should poll for the current config. It should keep polling every few minutes to verify that it hasn't missed any pushes.

But it should also register for push notifications of config changes so it can get them faster.

It should also renew its subscription if it finds that it missed an update during poling.

I mostly agree with you, but having spent a good part of my career dealing with data integration patterns, I'm all too familiar with the problem of missed messages from the consumer (or failed-to-send messages from the producer) that results in something downstream being in an incoherent state. The simplest fix for that incoherent state is often to also poll periodically, or something similar.

Sounds like it would share solutions with the “two generals problem”.

Push requires more engineering effort to build the server-side of the system. Poll is easier to implement for consumers, and probably also easier to scale for most engineering teams (scaling a central DB is a well understood engineering problem).

I agree that push is better overall, but… tradeoffs

In the real world: agreed on there being tradeoffs. But as a methodology?

Push can cause thundering herds while TTL expiration should occur uniformly over time.