Not only are those security problems non-existent - the problems caused by NAT are massive. You might not notice so much because services that don't work well with NAT essentially simply don't exist much nowadays, so it's difficult to notice them not working if you aren't aware what they would even look like. Though there are some obvious ones like remote access to your machines at home. Without NAT, you simply have to open the ports in your firewall and immediately, you can connect without any port mapping or stuff, you simply can give your machines at home DNS names and ssh into them.
Also, a major problem is not just the NAT itself, but the private addresses NAT tends to come with: If you have to somehow connect two networks that use the same private address space, things become incredibly hard to manage.
Also, NAT introduces major asymmetries in routing. Have you ever tried to connect to a service that's port-forwarded to an internal machine from your NAT gateway from inside the local network, for example? Well, either it will fail because pure DNAT means thet the reply packets will reach you with the wrong source address (because they don't pass through the NAT on the reverse path), so you suddenly need different configuration on the client side, depending on where you are when you try to use a service; or you have a device that does hairpin NAT in that case, which then means that the service doesn't see your actual IP address, but the address of the NAT gateway instead, which might give you confusing debug output/logging, and possibly non-working access control, and also causes your bandwidth to be severely limited by the speed of your NAT gateway, as all the traffic has to pass through the NAT gateway in order to rewrite the addresses of all packets, even though both endpoints are on the same LAN and might be able to transfer data at gigabit speed, if only there were no NAT involved.
There are possible operational security gains that can be permitted by ipv6, if operations groups permit...
For example, because of NAT and dynamic ip addrs allocation, my VOIP provider pretty much has to accept any ipv4 address in the world. My ISP's allocations are numerous and non-contiguous and my RFC1918 LAN address is meaningless from a security perspective. So anyone on the planet can log into my VOIP provider as if they're me, if they obtain my login info. That's kind of dumb.
However, with ipv6, with significant operational changes, it would be trivial to set up my account and firewall such that my VOIP device only talks to one specific providers /128 and my provider's account and firewall will only talk to my one very specific /128. Yeah yeah there are load balancing issues and device replacement issues such that a sane provider would operate on /64 sized networks both at their data center and my house, not individual devices. But it would be immensely more secure than ipv4, anyway.
There are other operational advantages. Currently with ipv4 companies usually don't have "an allocation" they have many, maybe dozens of little /27 here and a /28 there as they added devices. In the ipv6 world of the future companies will get a single /56 or maybe a /48 and call it good. So you get DDOSed or attacked or whatever, there's exactly one address range to block. Not 50 little ones depending on random DHCP address assignments. It'll be a much faster and simpler world. Doing egress filtering? They'll be one block to permit, thats all. Just one rule, not 75.
Also, a major problem is not just the NAT itself, but the private addresses NAT tends to come with: If you have to somehow connect two networks that use the same private address space, things become incredibly hard to manage.
Also, NAT introduces major asymmetries in routing. Have you ever tried to connect to a service that's port-forwarded to an internal machine from your NAT gateway from inside the local network, for example? Well, either it will fail because pure DNAT means thet the reply packets will reach you with the wrong source address (because they don't pass through the NAT on the reverse path), so you suddenly need different configuration on the client side, depending on where you are when you try to use a service; or you have a device that does hairpin NAT in that case, which then means that the service doesn't see your actual IP address, but the address of the NAT gateway instead, which might give you confusing debug output/logging, and possibly non-working access control, and also causes your bandwidth to be severely limited by the speed of your NAT gateway, as all the traffic has to pass through the NAT gateway in order to rewrite the addresses of all packets, even though both endpoints are on the same LAN and might be able to transfer data at gigabit speed, if only there were no NAT involved.