Personally, I don't find these to be breaking issues for my use. My only issue is that the PiHole interface's administrative features are authenticated via the PiHole's service user account password. This is the Ubuntu user password for the user the service runs under when installed on Raspbian or whatever. There's no secondary credential store. There isn't even a list of users. To log in, you enter the user's password. If there was a way to assign credentials to network users and allow them to whitelist/blacklist entries and audit that, it could easily be much more non-technical user friendly.
One final half complaint. If a link is direct to a blocked site that is served over ssl, you won't get the nice "This site has been blocked" page. It will just show the standard Chrome/Safari/Firefox "could not connect" error. As a technical user, this is normal and makes sense. For others, it makes "the internet" appear "broken". Obviously this isn't something a PiHole can fix on it's own, and I don't expect it to. It's a slippery slope to add a trusted root or intermediary cert to each of my network devices and allow a random box on my network to dynamically "poison" my DNS and serve fraudulent dynamically generated site certificates just to show me an informational page to allowing a random box on my network proxy and DPI my SSL traffic. It's not something I'm comfortable with maintaining.
https://gist.github.com/ryandrake08/bd2616eacbf2565243ffee74...
Also to people redirecting ad servers to 0.0.0.0, that can cause page damage particularly with things like iframes. Pi-hole instead redirects them to its own webserver and serves up 1x1 pixel transparent images to avoid this.