Publishing on third-party platform, with content limited to what those platforms allow, with monetization limited to what those platforms allow, with constant exposure to random nonsense DMCA takedowns.

But I guess the primary culprits of limiting people's ability to be publishers are NATs.

Even crappy home routers can port-fwd, the real barrier here is the ubiquitous (in America at least) prohibition on "hosting a server" on a residential internet connection.

You think everyone serving their own services from their residential networks is the solution? Have you thought through the security implications of that?

I can just imagine the technical support hours I'd have to log when my dad calls me up because his email server is down or his home storage is encrypted by ransomware.

Of course I have, that's why I run pfSense, a separate host for my DMZ, a reverse proxy, an IPS, and don't have DNS pointing to it (marginal benefit, but I don't need it so it's off).

I'm not arguing that people should do this, I'm arguing that the "NAT is a barrier" position espoused by the "evil ISPs are trying to keep us down, man" camp is incorrect.

NAT being necessary because of IPv4 has lead to this really useful low barrier to self-hosting. People who grok security and want to do it can, but it's just arcane enough that lots of people who shouldn't self-host are scared off and go to AWS.

How does that work with WebRTC, e.g. as used in messaging apps?

You've lost me, what's the connection between "people's ability to be publishers" and WebRTC messaging apps?

If you want to publish a WebRTC service, port forwarding will work fine and then you'll be bitten by the no servers restriction.

A messaging app doesn't have to require port forwarding, it can use a central server to broker the connection between endpoints. In that scenario, the "server" is on the internet, not the residential connection, but data comes from the endpoints.