The implementation of NAT Hairpin itself is ugly.
Given this scenario
Host A on LAN - 192.168.1.100
Server on LAN - 192.168.1.50
Host A -> WAN IP address (ROUTER DNAT to 192.168.1.100 AND SNAT 192.168.1.50)
Router -> server
server -> router (DNAT / SNAT reversed)
router -> host A
For EVERY connection that's hitting your server from your LAN.
For a SOHO network, this might not be a problem ... but that obviously depends on number of connected devices using the hairpin, and number of services that rely on it. While it takes more "setup time" (not to mention learning), local DNS doesn't exhibit the same issues with "weird access errors" that hairpin can.
Also, your "workaround" is "hairpin nat with different words", and will exhibit the same issues as I've laid out. The whole point of NAT hairpinning is letting the router decide "oh wait, they're trying to hit my WAN IP address, I should check my rules and see what to do" -- rather than letting the packet go out to the ISP's routers, and get sent back.