Also, v6 addresses aren't necessarily hard to remember. For example, here's a URL for accessing a site over v4: https://www.sprint.net/, and here's the v6 equivalent: https://www.sprint.net/. It's hardly more difficult to remember the second than it is to remember the first.
The first thing you do when diagnosing/troubleshooting IP-based issues is totally ignore DNS (since it's not acually part of IP) and start throwing around IP addresses.
When doing tcpdumps, network/router tracing, no-one gives a toss about DNS.
To use DNS requires registering something somewhere i.e. additional paperwork and/or configuration. Which is pointess when running up a quick service to do/check something.
Most of the organisations I've worked at don't use DNS inside device/appliance configurations, e.g. all the firewall devices use IP addresses, not DNS. Load balancers likewise (i.e. when configuring new end services, the networking team who look after the firewalls, load balancers, and other devices want IP addresses, not DNS names).
When you are diagnosing a problem from an end user out in la-la land, the only DNS address you are interested in is the one they are hitting initially. From that point in through the rest of the infrastructure, it's all IP addresses that are looked at.
Original DNS -> IP -> firewall1 -> Load balancer (IP) -> multiple endpoint IPs -> security service IP -> Load balancer (IP) -> multiple IPs -> firewall2 -> end points -> more load balancers ...
And there may very well be multiple NATs in there as well for security purposes (and ease of configuration in some cases, especially in B2B VPN situations).