As explained:
This is not about TTLs from public resolution.
local-ttl controls TTL of the values that Pi-hole is administering, e.g. Local DNS records or DHCP lease hostnames (if Pi-hole is acting as DHCP server).
Likely, you wouldn't want clients to continue with outdated information and to wait for an hour or two before clients would re-request resolution of a local DNS record that has been changed by you in the meantime.
In the past, e.g., this would also have affected domains that you'd have blocked manually in Pi-hole. (from Pi-hole's September 2021 release, Pi-hole uses a separate TTL for blocked domains).
Note that pihole-FTL /dnsmasq is defaulting local-ttl to zero:
local-ttl=<time>
When replying with information from /etc/hosts or configuration or the DHCP leases file dnsmasq by default sets the time-to-live field to zero, meaning that the requester should not itself cache the information. This is the correct thing to do in almost all situations. This option allows a time-to-live (in seconds) to be given for these replies. This will reduce the load on the server at the expense of clients using stale data under some circumstances.
My suggestion of a few seconds to a few minutes would try to strike a compromise here.
My recommendation was to keep only local-ttl, and remove the other four cache and ttl related options from your configuration.