
Many organizations have split DNS already as a result of not wanting to publish all of their internal DNS information to the world, so it isn't much additional effort to handle the few servers that are also exposed via a public IP. When troubleshooting network issues, the crew would need to be aware of the hairpin NAT configuration and all of its implications - even when they are chasing an apparently unrelated problem CIACO ASA NAT REFLECTION ONE PUBLIC IP ADDRESS HOW TO
Not every boundary router would support loopback NAT in a straightforward way, less people are likely to know how to set it up correctly in your specific environment. Portability and common practice: Using DNS views is "just the thing everybody knows is done" to solve this problem.
In order to ensure that changes are not delayed by the firewall admin's backlog (or vacations), the option to keep the responsibility in the same team is chosen Reference: wherever firewall admins are different folks than the rest of the server admin team, they might be difficult to reach.Either that or you would have to spread and maintain the NAT rules across nearly all of your router devices.
Complexity: especially in a case where you do not have just one single "core" router creating all of your security boundaries, filter configuraions can become quite tricky. With IPv6 the problem is going away at any rate. Elegance: NAT is not very elegant to begin with, but a necessity with IPv4's restricted address space. Obviously, there cannot be the definite answer for this, but I could think of a number of reasons: