

I presume you mean running Plex in host namespace. I don’t do that as I run the synology package, but I can totally see the issue you mean.
Running in host namespace is bad, not terrible, especially because my NAS in on a separate VLAN, so besides being able to reach other NAS local services, cannot do do much. Much much much less risk than exposing the service on the internet (which I also don’t).
Also, this all is not a problem for me, I don’t use remote streaming at all, hence why I am also experimenting with jellyfin. If I were though, I would have only 2 options: expose jellyfin on the internet, maybe with some hacky IP whitelist, or expect my mom to understand VPNs for her TV.
(which doesn’t harden security as much as you think)
Would be nice to elaborate this. I think it reduces a lot of risk, compared to exposing the service publicly. Any vulnerability of the software can’t be directly exploited because the Plex server is not reachable, you need an intermediate point of compromise. Maybe Plex infra can be exploited, but that’s a massively different type of attack compared to the opportunities and no-cost “run shodab to check exposed Plex instances” attack.
Wow, those are big networks. Obviously I suppose in case of AWS it doesn’t matter as no human visitor (except maybe some VPN connection?) will visit from there.
As someone who bans /32 IPs only, is the main advantage resource consumption?