You have to distiguish between the different approaches used to accomplish this (not all of which are technically hardware NAT, but still serve the same purpose of speeding up WAN to LAN throughput).
- what is typically referred to as hardware NAT by the OEM firmware (involving only partially open, device specific code). No, this has basically no chance to be be merged.
- QCA fastpath, which makes up the laters parts of this thread, is relatively hardware agnostic and basically employs heuristics to bypass large parts of the kernel's network stack in cases it deems safe. Due to the fact that it isn't tightly coupled to very specific hardware or ancient kernel versions, this has a slightly better chance of being merged. But, this is still a huge amount of code, which is placed into extremely sensitive code paths and has basically zero chance of getting merged into the upstream kernel, where it would also get further auditing and scrutiny.
- new DSA based drivers under development for common switch hardware (qca8k, mt7530-dsa), which are a clean re-implementation of hardware acceleration within the upstream kernel framework. These have a rather good chance of getting merged (upstream and for LEDE), once the remaining bugs have been fleshed out (these will also profit from the pending support for multiple CPU ports for the DSA framework in the future) and after a conversion strategy for the switch configuration has been added. This likely needs a bit more time.