Out of interest, why didn't you just bridge the two interfaces? Did you want everything on a separate subnet? (maybe I missed that but but you mentioned before how everything used to be directly plugged in anyway)
802.11 has the concept of "transmitter address" and "receiver address" in addition to source and destination. Those are MAC addresses too, but they're relevant for the on-air radio management. Things like RTS, CTS, ACKs, and fancier things like beamforming and sounding. The problem is that the design only includes 3 address fields in on-air frames; the AP can specify separate SA and TA (i.e. send a packet for somebody else, SA=real source, TA=AP MAC, RA=DA=client.) There is no mechanism for the client to do the same thing; that would require 4 address fields.
Coincidentally, 4 address fields is exactly what you get with "WDS" / "Wireless Extender" / ... modes. However, these need to be supported, enabled and configured on both the AP and client. The author of the post seems to have no access to the AP to do so (and the AP possibly doesn't support it anyway.)
There is also a new standard that covers 4-address frames, 802.11ak; I have no idea how widely that is adopted though — it was only released in 2018[1].
[1] https://standards.ieee.org/news/2018/ieee_802_11ak-2018.html
On a technical/complexity level, IP NAT is much worse because you need to hold much more state, i.e. you need the UDP/TCP flow information to rewrite correctly.
However, MAC NAT is the pinnacle of stupidity for an entirely different reason: there should be no need for it. MAC addresses only have local significance, and while there are some long-term concerns about them running out, there is absolutely enough of them right now. There should simply be no need to do MAC NAT, if only it wasn't for the shortsighted 802.11 design decision to go with 3 addresses in the header.
FWIW, MAC NAT is almost the same thing as a router with ARP/ND proxying turned on, though possibly implemented on a different level. This is the technical reason it's an extremely stupid hack: proxy ND/ARP provides pretty much the same thing, but in a much cleaner way. (The difference is that with proxy ND/ARP, the "router-ish-bridge" assumes ownership of the lower-layer exchanges, i.e. ARP & ND, and just does normal routing with that. MAC NAT, meanwhile, tries to be clever and just forward ARP and ND. Reasons for doing that are ... extremely thin IMHO.)
Thanks for that. Filed away for future use.