Every argument I've heard against NAT being an effective practical mitigation for home users runs smack into the problem of being a oh-well-actually scenario that's fantastically contrived and doesn't represent a realistic threat model for the average home user.
For an inbound connection again, there is a packet filter first, that will permit inbound connections based on whatever filter parameters are defined (usually matching established sessions, or new sessions filtered by just protocol and dport), and if that clears, the second step is NAT.
In both cases, the filter happens before the translation.
He's correct that the NAT doesn't stop the connection, but the stateful firewall is another service on the same device so you will never really notice the difference
With the theoretical situation of a NAT without a firewall a connection is technically possible, as long as you are able to inspect any previously sent TCP packets and use the sender bits to route your new packets
If I send a packet from SRCIP1:SRCPORT1 to DESTIP1:DESTPORT1, and his real desktop IP is DESTIP2, the first event to occur is the stateful firewall checks if there's a session that exists between SRCIP1:SRCPORT1 and DESTIP1:DESTPORT1.
If the session does not exist, the firewall drops the connection.
If the session does exist, the next step is to hit the NAT table, to look up what to translate, for session SRCIP1,SRCPORT1,DESTIP1,DESTPORT1 into SRCIP2,SRCPORT2,DESTIP2,DESTPORT2.
Note that it's possible that source ip, source port, destination port may not change in this scenario, where there's an RFC1918 DESTIP2. It depends on the NAT configuration.
So again, strictly speaking, NAT does not prevent the connection. The stateful firewall does. NAT does not protect you, the firewall does.
"Old fashioned stateless firewalls" are also not widely deployed on consumer grade CPEs.