You lose the concept of DNS forwarding. Usually, if your company has example.com, your DNS server is authoritative for example.com, which means it will actually contain (fqdn,ip) entries belonging to example.com, and it will forward requests for other domains to other DNS servers, possibly one DNS server per domain.

If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on.

You don't have PTR records, which means you can't find out a name from its IP address.

You also miss other features of DNS, like SRV, MX and so on.

More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.

Serious answer: I run [and must maintain] 100x fewer resolvers than hosts. If an endpoint changes or a host leaves/returns, I'm much better served (heh) by pointing templates at resolvers instead of the horde.

Because managing one database using mature tooling that is purpose-built is easier than managing 10,000+ databases using a homegrown solution with exponentially more complicated software that wasn't built for that purpose.

If you're worried about bad DNS changes causing problems, then you should be terrified about bad Ansible changes.

Changes from a single point of failure to a thousand points of failure. What if a host if offline when the Ansible update runs? What if someone wants to run a service that ignores /etc/hosts, like a Docker container?

As an /etc/hosts enjoyer, I wouldn't want Ansible overwriting my customized hosts file.