I expect that you created the replica in a manner that preserved the logical replication slot on it. You also had hot_standby_feedback enabled.
As per both you and Andres' replies, we wanted the backup to have the logical slots on it, because we wanted to allow decoding from the slots on our backup. However, what we should have done is drop the slot of the backup on the master.
PostgreSQL standbys send the global xmin and (in Pg10+) catalog_xmin to the upstream when hot_standby_feedback is enabled. If there's a slot holding the catalog_xmin on the replica down, that'll be passed on via hot_standby_feedback to the upstream. On Pg 9.6 or older, or if the replica isn't using a physical replication slot, the catalog_xmin is treated as a regular xmin since there's nowhere in PGPROC or PGXACT to track the separate catalog_xmin. If the standby uses a physical slot, then on pg10+ the catalog_xmin sent by the replica is stored as the catalog_xmin on the physical slot instead.
Either way, if you have hot_standby_feedback enabled on a standby, that feedback includes the requirements of any replication slots on the standby.
Thank you for the thorough explanation. As I noted in my reply to Andres, we routinely and intentionally create snapshots with replication slots intact (but we normally drop the slot on the master immediately), so our own use case is rare and it's not surprising that we don't find a thorough explanation of this scenario in the docs.
