If this helps you understand, NAT and stateful firewalling are often the same code base. NAT is basically just a sub-feature, purely for translation, that is it.

The NAT feature solves the problem of:

  - public ipv4 exhaustion

You get in return:

  - higher latency

  - higher user & administrator mental overhead

  - limited public ports

  - protocol breakage (TCP & IPSec)

If you _remove_ NAT:

  - users no longer have to figure out why they can’t connect to their local web/minecraft server using the public address/domain even after a port forward (the very common NAT hairpin problem)

  - do not need to google “what’s my IP” as the machine knows its address in any context

  - do not have to tunnel to a VPS, or use a VPN in cases of CGNAT (ISP provided double-NAT) to expose a server
 
  - no longer have to maintain a split DNS zone for public/private addresses of a *public* server

  - no longer have to google “how do in enable NAT traversal for this VPN”

  - no longer have to learn what addresses are OK and not OK to use locally (rfc1918)

  - no longer get confused into thinking NAT is a hard-requirement for any and all routing (ex: green admins whos only experiance is a basic pfsense install adding 3 layers deep of NAT in labs) 

These are all problems I’ve either been paid to help figure out, or done for free on forums/discord, regularly.

Removal of NAT requires no user interface change, the same “port forward” terminology AND user interfaces can remain. There can still be a port forward tab where you enter an address and port. SOHO firewalls/routers that use stuff like iptables ALREADY add both NAT and normal firewall rules, and hide that fact. The security of user devices with a proper firewall/router does not change, the exposed interfaces do not need to change, everything gets simpler. I repeat, the basic abstraction presented to users does not need to change. The only reason to insist on NAT is ignorance; removal of NAT is removal of complexity.