That’s right, we’re starting to do offtop, but on the other hand, a bit of healthy discussion has never hurt anyone and maybe one day someone will read it and learn something new. 
Discussion about blocking traffic as well as dns should start primarily with the assumptions of a given network and the user’s needs. Otherwise, we’re chasing a bunny…
I configure my private network differently than my work network.
It all depends on the concept and needs. I don’t waste time redirecting udp 53 traffic to my dns. I block it, and either the device allows manual setting or honors what dhcp says about dns… otherwise gtfo with something like this from my network.
Another thing is that I start controlling network traffic already at the end point. If only the device has an OS where I can set a firewall, I run it and control it per application, per device, only at the end is there a firewall on the gateway.
Before anything touches the rules on the gateway against tcp 443 it must first be able to access tcp 443 through the local firewall. Where traffic is usually limited per application/system service and specific protocol, port, and destination ip.
For example, some Windows machine, let’s try to establish communication with tcp 443, here it must have a rule that will allow this particular process to do this traffic. If there is no rule, traffic will not go through even though centrally tcp 443 is open.
Of course, this is not an option in the case of tv where we do not have the freedom to operate with fw. The problem is the very fact of using smart tv which is evil in itself.
You can also block known DOH/DOT servers… but that doesn’t affect the OP’s case too much.
You can of course play around with deep packet inspection for tcp 443 to identify smuggled dns traffic. theoretically possible, there are known cases where dpi can even handle tor or openvpn masked traffic. But here we are already in deep water.
Theoretically, we could try to implement port knocking/single-packet authentication to mark legitimate tcp443 traffic from a hostile one. But that already requires some deep digging… to limit your hostile dns payload via tcp443
And the conclusion, keeping it simple, is that pi-hole can’t handle ads on youtube, even if tv where 100% uses this dns. 
Others have already suggested an alternative approach instead of smart tv directly.
. Hell it can be easily done with flutter (flutter.dev). DNS tunnels are something you could easily implement. I literally if I was nefarious enough could write a seemingly normal app and point it to a non standard port with DNS over TLS elsewhere and have a built in resolver bypassing network consent altogether.