This is just to clarify my suggestion, not to criticise your choice.
I cannot know all of the intricacies and use cases in your network, so my advice has to be somewhat generic. Whatever is understood by and working for you is obviously your optimal solution. 
Your examples seem to ignore my precondition.
I am not suggesting to get rid of public resolution. DynDNS is a valid use case.
I am proposing to move exclusively those subdomains under Pi-hole's control that need internal, private address range resolutions only.
This makes your examples 1. and 3. not applicable.
2 is valid, but should be addressed by configuring your router to redirect your network's DNS traffic to Pi-hole. If that's not possible, have your router block outbound DNS for any device but Pi-hole to much the same effect.
Even if your router would support neither, my preference would be to cage any misbehaving fixed DNS devices behind a dedicated extra AP or firewall of their own. To me, it seems just wrong to rely on an external service for things that are internal only.
If that means duplicating private and public IP address resolutions alike, note that traffic may be flowing slower than it could when public IPs are used, as two devices on your network may communicate via your router instead of talking to each other directly, and in case of an actual Internet outage, clients may try public IP addresses first in vain before falling back to the private IP.
In addition, you may also run into issues with certain reverse lookups for private IP addresses (see e.g. Answer PTR Queries)
If public IPs are not necessary for other reasons, you should try to eliminate them. If you can, you would use only private IPs, and that would again suggest you could put those entries under Pi-hole's control.