Why does creating logical replication subscriptions require superuser?

Hey, all,

I'm working with native logical replication, and I don't fully understand
why logical replication subscribers need to be superusers, nor do I fully
understand the implication of some of the comments made on this page:

https://www.postgresql.org/docs/current/logical-replication-security.html

> A user able to modify the schema of subscriber-side tables can execute
> arbitrary code as a superuser.

Does "execute arbitrary code" here really mean executing arbitrary code on the
machine that is running Postgres, or simply running arbitrary SQL in the
replicating database? Would it only be able to modify data in the database
containing the subscription, or could it modify other databases in the same
cluster? Is there any "blast-radius" to the capabilities gained by such a user?

According to the commit message that added this text, the callout of this
point was added as result of CVE-2020-14349, but the details there don't
really help me understand what the concern is here, nor do I have a deep
understanding of various features that might combine to create a vulnerability.

I'm not sure what arbitrary code could be executed, but my rough guess, based
on some of the other text on that page, is that custom triggers, written in
an arbitrary language (e.g., Python), would run arbitrary code and that is
the concern. Is that correct? And, if so, assuming that Python triggers were
the only way to execute arbitrary code, then simply building Postgres without
Python support would prevent users that can modify the schema from executing
code as superuser. What is the full set of features that could lead to running
arbitrary code in this scenario? Is it just all the different languages that
can be used to write triggers?

Essentially, I'm wondering what a loose proof-of-concept privilege escalation
vulnerability would look like if a non-superuser can modify the schema of
subscriber-side tables.

On a related note, what happens if a superuser creates a subscription, and then
is demoted to a regular user? My understanding is that the worker that applies
the logical changes to the database connects as the user that created the
subscription, so would that prevent potential vulnerabilities in any way?

Thanks,
Paul