If malware can modify /etc/hosts, then it shouldn't have any problems modifying Firefox executable or, even easier, it's configuration.

This is true, but most malware is neither high-effort nor high-quality. It's very easy to edit /etc/hosts. It's a lot harder to inject yourself into the binary in a way that works. It's harder still to inject yourself into the binary in a way that works if the binary is actively trying to not be injected into, or using some security-by-obscurity scheme for signing the config, or whatever. Yes, it's all running at the same privilege level (or lower) and the malware technically has the access, but it's not cost-effective to have battle-hardened automatic reverse-engineering tech built into your malware.

Chrome in particular has a DLL blacklist that seems to work very well in practice: in theory, a DLL blacklist can't possibly work, but in practice, DLLs don't try hard enough to hide their existence from the blacklisting code. https://www.chromium.org/Home/third-party-developers#TOC-Goo...

Yes but you don't need any of that in this case, Firefox's config files are easily editable to toggle am option like using DoH.

The fun with malware will only start, once it starts finding it's command and control centers using DNS-over-HTTPS to a shadow DNS served by botnet and you won't be able to filter out it's traffic.

Also as other have pointed out you can run you own TRR locally as a daemon and have it look to /etc/hosts

Yes, and configure each app on each computer separately, instead of DHCP or RA, and if you miss some app, it will masquerade it's resolving among the rest of https traffic. Great. That's progress /s.