NAT changes the apparent destination address of a connection, it doesn't filter them. If a connection arrives with the destination address already set to one of your machines, NAT won't prevent it.
NAT is not a security device. A firewall, which will be part of any sane router's NAT implementation, is a security device. NAT is not a firewall, but is often part of one.
Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.
Even a correctly-configured NAT will let connections in from outside, and a lot of people don't understand this.
Personally I'd count "your security thing doesn't actually do the thing it's supposed to do" as being pretty bad on the security scale. At least people understand firewalls.
NAT doesn't apply to inbound connections if you don't have a matching port forward rule, so it kind of doesn't matter how NAT works here. This is pure routing, not NAT.
IPv4 requires a DHCP server. It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network. The range must never conflict with any VPN you use. And there's more. Compare to IPv6: Nothing. All of these just go away.
And concerning the NAT: That's just another word for firewall, which you still have in your router, which still needs to forward packages, and still can decide to block some of them.
Windows[0]: Static IP configuration is as simple as typing an IP address into the pretty dialog box. No DHCP required.
Linux[1]: # ip addr <ip4 address> <subnet mask> <device> will set a static IP address
>It requires assigning a range of addresses that's usually fairly small, and requires manual configuration as soon as you need more than 254 devices on a network.
Is 65,536 (172.16.0.0/16) or 16 million addresses (10.0.0.0/8) "fairly small"? Are DHCP servers unable to parse networks that "big"?
>Compare to IPv6: Nothing. All of these just go away.
They most certainly do. But they're not "problems" with RFC1918 addressing and aren't "problems" at all with IPv4.
There are many issues with IPv4 and the sooner it dies, the better. But the ones you mention aren't issues at all.
If you're going to dunk on IPv4, then dunk on it for the actual reasons it needs to go, not made up "problems."