Of course.
It is beneficial to handle large DNS replies over UDP without having to fall back to TCP. Retries can easily add unnecessary delays of up to several hundreds of milliseconds. The value of 4096 hasn't been invented by us but is suggested by the ENDS Internet standard, to be precise, RFC 6891 Section 6.2.5:
6.2.5. Payload Size Selection
Due to transaction overhead, it is not recommended to advertise an architectural limit as a maximum UDP payload size. Even on system stacks capable of reassembling 64 KB datagrams, memory usage at low levels in the system will be a concern. A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.
A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry.
Values of less than 512 bytes MUST be treated as equal to 512 bytes.
Emphasis on the second paragraph. This is exactly what Pi-hole does. We implement the optional fallback ("MAY") and first try with a packet size of 4096 ("SHOULD"). We then drop to a value of 1280 ("SHOULD") if that doesn't work. We do not try a third time with 512 bytes ("MAY") and immediately retry over TCP as a network that cannot even handle 1280 bytes properly in one packet is considered severely broken and other things are expected to fail, too.
It is exactly here:
But it also was in the thread you posted your reply in, first.