Firewalls are capable of providing all of the positive benefits of NAT (transient traffic flow approval instead of mapping for example, blocking traffic not originated from the LAN, etc) save obfuscating the source address. Obfuscating the source address isn't particularly relevant from an attack perspective given that the entire LAN is still protected by the same Firewall process, NAT or not.
For example: you could NAT your LAN in 192.168.10.x space behind IP 1.2.3.4 .. you connect to shady.com port 80 sport 192.168.10.101:2000, NAT/firewall allocates 1.2.3.4:3000 for you. Shady sees all the traffic coming from 1.2.3.4:3000, but has no way (short of client-side malware) to know that maps to 192.168.10.101; nor can Shady care since all access to 192.168.10.101 is mediated by 1.2.3.4. Shady.com might try to port scan 1.2.3.4, and see any port forwards your entire LAN uses in one swoop, try to exploit them if possible. Moral: make sure you know what you are doing when you port forward.
Or, if you use IPv6 for your LAN, let's say you are allocated 1:2:3::/112. No need to NAT it, so you just firewall behind your gateway, let's say 1:2:3::4. You connect to shady.com port 80, sport [1:2:3::101]:2000. Firewall doesn't have to allocate a damned thing for you, but instead records the flow for [1:2:3::101]:2000 shady.com:80 as established from within the LAN and thus authorized. Shady sees all the traffic coming from [1:2:3::101]:2000, but it's not relevant since all access to 1:2:3::101 is still mediated by the firewall at gateway 1:2:3::4. Shady.com can port scan 1:2:3::101 if it likes, but won't see any open ports if you only allow LAN established traffic, or else sees your whitelisted ports for that IP only (instead of your entire LAN). Just like the IPv4/NAT scenario, keep your open ports secure.
As you can see, source IP obfuscation provides no meaningful advantage to the end user in this scenario. If anything, IPv6 users who feel like they want to use NAT could have the firewall choose random source addresses as well as random source ports out of their /112, and hide their 3 LAN devices within a pool of 65 thousand addresses. Would that not confuse a would-be attacker?
Still, the major drawback to be avoided with NAT is in breaking the globally unique address space and complicating inbound connection access, which will become a growing part of popular network policy over the next few decades. One thing Bit Torrent teaches us is that "the server" will less and less frequently have resources comparable to the "client swarm", so crowdsourcing the heavy lifting (from distribution to content creation to editing to caching) becomes vital to any scaling strategy worth it's salt. The hub/spoke communication model is slowly eroding in the presence of more sophisticated, decentralized many-to-many connection models.
NAT reduces a peer to a "consumer" which can only fetch data, but never re-offer it without convoluted port forwarding messes. Entire LAN's are limited to one named service per outbound IP, unless one wishes to screw with what port they offer services on, further complicating the job for other firewalls and participants of the content network.
You'll know what I mean if you've ever tried to configure mobile SIP access. Half the time you are behind a NAT, and you'll never know in advance if it's full cone, symmetric, or just somehow pathological. Sometimes you are nested within multiple NATs which each behave differently!
Some legacy UDP protocols I've worked with need to make connections to thousands of remote IP addresses at multiple, highly transient port mappings which bring NAT mapping tables to their knees. In a firewall-only environment, it's easy to whitelist access to swaths of ports for clients and then the gateway need not maintain tables for related traffic, but can continue to protect unrelated ports unlike with SOHO DMZ.
To sum up, NAT is not only a bandaid, but it's already pulling at our short-hairs.
