They MITM all the DNS and HTTP traffic by nature of what they do. T
Well, you have to get your DNS from somebody, and they will know what they are giving to you. The big American ISPs don't just let big brother watch, they also sell your requests and put their own ads in place of NXDOMAINs. If you ask me, cloudflare and google are still a step above even if they still sell the data and let big brother watch, so long as they don't mess with NXDOMAINs. Leads on DoH services that don't sell your requests and/or don't let Big Brother watch would, of course, be constructive and appreciated. I just think it's a bit ungrateful to complain that an improvement you're getting for free doesn't go far enough.
Ditto for the Poettering-pocalypse. Yeah, it's annoying as hell when he steps on your toes (the last time it affected me was when systemd-resolved broke dig +trace without an explicit server argument) but on the whole I'm glad it's happening. Name services always should have been handled per-link and per-service and always should go through a system wide cache layer that knows about links going up/down/reconfiguring for cache flushing purposes. /etc/resolv.conf, /etc/nsswitch.conf, and in-process glibc name resolution were always a bad fit for the modern network environment with complications like mDNS, NBT, and split-horizon resolvers from VPN connections and I'm glad somebody addressed that, even if I have to suffer a very minor inconvenience to obtain the benefits of said modernization.
Same goes for systemd as a whole. Compare the pile of RC scripts and runlevels in an old distro with the systemd units in a new distro. Are you really going to argue that declaring dependencies through a distro-specific mishmash of runlevel numbers, RC script precedence hierarchies, serialization scripts, file name alphabetical ordering, magic files, unparsed script comments, parsed script comments, and sleep <magic time> is better than having each unit declare a Require= line? Or that letting every service reinvent supervisory restart, centralized search/compressed/forward-secure logging, start-on-demand, and dependency watching in 5 different ways so as to maximize bugs and minimize knowledge transfer is a good idea? I sure wouldn't. I love being able to get all of that with at most a line or two in a unit file, rather than 30 lines of shell script and a trip every other month through TTY archana, and I *especially* love that the knowledge I gain by doing so instantly translates to all of the other services on my box.
Besides, doesn't it just make you smile every time you
journalctl -fu misbehaving-unit
or, when things get really rough,
journalctl -fk
? No? Just me?