I couldn't have put it better myself. I don't think the person who wants convenience has enable on any ASes routers, or at least I hope not. One thing I find interesting is that they're using 169.254/16. Doubtful Google uses DHCP for anything, their automated provisioning tools are probably quite unique. My best guess is that their stuff in that particular part of app engine is using the space because they've actually near exhausted the rest of rfc1918, which is pretty impressive.
The only other organization I know of that has done that is Comcast, which has been a leader in forcing vendor ipv6 support because they literally exhausted 10/8 for their management networks.
And yet Google still believes VPN as a security boundary is an anti-pattern since the whole intranet is as weak as it's least secured node. https://cloud.google.com/beyondcorp/
The benefits of being able to resolve internal IPs external isn't even really a benefit - if I can't resolve internal.hostname.domain then I'm not on the VPN, which means I can't reach the machine anyway, so where's the benefit?
A perfect example of why this threat isn't merely theoretical is the $36k bug bounty that Google paid out recently[0]. With additional knowledge of their internal network exposed by the information leak from DNS, the damage a blackhat could have done is untold.
The problem isn't the exposition of hostnames and addresses, the problem is if blackhats do manage to get access to the internal network (through whatever means; breaking into the VPN, a hole in the firewall, social engineering, RCE in the public facing website as in Google's case), it's undoubtedly easier if they've been given a list of juicy targets, rather than have to discover them for themselves.
[0]https://sites.google.com/site/testsitehacking/-36k-google-ap...