Actually, there is! People normally don't notice because NAT is usually co-located with a stateful firewall (since both need connection tracking to work, unless it's the rarer 1:1 NAT). But you can run NAT with firewall disabled, and in that case, it's possible in some cases for a device on the outside to access a device on the inside.
For instance, suppose a NAT router with 192.168.0.x/24 on the inside, and 192.0.2.1/24 on the outside. A malicious device at 192.0.2.2, on the same level 2 network as the router, wants to attack a host inside the NAT. The malicious device can send a packet with IPv4 destination address 192.168.0.x and the Ethernet destination address of the 192.0.2.1 router; if that router has its stateful firewall disabled, it will accept the packet and route it to the target device.
That is: what "protects" devices on a NAT without a firewall is not the NAT, but the use of non-globally-routeable addresses within the NAT, since a packet from the outside won't find a route to your NAT router; but if someone manages to route the packet to your NAT router anyway, it'll be accepted unless a firewall rule blocks it.
(If you want non-globally-routeable IPv6 addresses, you can use ULA addresses, which have similar properties to the IPv4 private addresses.)
The post you replied to was talking about stateful NAT. Stateful NAT doesn't firewall either. If you do what they described, you'll be able to connect in just fine unless there's a separate firewall blocking it.
A perfectly reasonable NAT implementation will allocate a router TCP port for an outgoing connection from a private IP, and will send ANY traffic that reaches this port to that private IP.
So, if I send traffic from 192.168.0.78:19990 to 1.1.1.1:443, the NAT may allocate TCP/29099 for this connection and forward traffic from its public IP, 3.56.54.90.
Then, if an attacker sends a SYN packet to 3.56.78.90:29099, the router will forward that packet to 192.168.0.78:19990. The machine may or may not accept that connection, but the attacker has reached it.
Now, many NAT implementions also do firewall-style tracking, and would not accept this packet unless it came from 1.1.1.1:443. But that is not required for NAT to work, and it requires extra memory per connection (storing the destination IP/port as well as the local IP/port), so I'd bet real devices exist that do this.
Actually, unless you disable all application layer gateways in your NAT, your IPv4 firewall can be bypassed quite easily. I don't know of any IPv4 NAT implementations where the ALG don't override the firewall (because that's the point of them).
If you configure NAT+firewall you're going to be somewhat resistant to configuration mistakes, but you can do the same thing on IPv6 if you really want to. However, for most consumer devices, all you get is "NAT instead if a firewall WITH NAT bypass methods so you can still use SIP and FTP".
