Google's DNS servers are a product meant for public use, i.e. this use. I think it is entirely reasonable to not run your own public DNS servers as an Open Source software and instead use a well-maintained already existing one that has an excellent track-record of availability and low latency.

That in itself I'm not sure I have an issue with 100%...

It is the only DNS servers that are guaranteed to have accurate results and respond quickly. The only time I use local DNS inside of my LAN is when I need local LAN entries.

The issue I have is it not reading /etc/resolv.conf, but if resolv.conf isn't setup or setup properly, falling back to Google's is a good solution.

Also, at my company (we do DDoS mitigated dedicated servers), we deploy servers with Google's set by default: we have access to Google over Equinix IX, going out to 8.8.8.8 responds as fast or faster than it does with bind, dnsmasq, and unbound, even when the entry is clearly already cached, with the DNS cache daemon running on a server in the same rack; and for uncached, Google is usually much faster.

Am I missing something? In the linked thread they say it reads /etc/resolv.conf and its entries have precedence.

Doesn't work so well when you take your laptop with you on travvel to China?

If by "hardcodes" you mean "can be changed in the configuration file", then yes, that's true.

The issue is that if no configuration is available/found/readable things doesn't stop working with a sensible/expected error - but rather enters a new and unexpected (error) state. Error if you didn't want to use Google's resolvers.