What website are you running where older Safari clients are 99.999% of your hits?
(of course, JPEG-XL adoption is mostly beneficial when most of your clients support it, hence the discussion here)

Even if none of your clients support it, depending on the access pattern, you could minimise server load increase if you can employ effective caching. I've done on a site where a lot of images are stored, but the vast majority of accesses only touch the latest images - most of these get served from cache, and only a few get generated on-the-fly.
Of course, you can delay such adoption until most of your clients support it.

Or just ditch WebP, store only JPEG-XL and assemble JPEG on-the-fly (from the JPEG-XL source) when requested. So yes, you can get the full benefit of space savings.
(keep in mind that JPEG-XL was explicitly designed to be able to reconstruct JPEGs)

HEIC is a patent nightmare though, so doubtful it'd get widespread support in browsers (though Chrome recently added HEVC decode, so who knows; I doubt Firefox would adopt it).

Those serving images could gain a fair bit from aggregate bandwidth savings, as well as reduced storage costs. Also helps those on metered connections. There's also other features JPEG-XL has, such as resistance towards generation loss, which is useful regardless of compression benefits. Finally, keep in mind that it was Google who pushed hard on their WebP format, despite criticism that it didn't really bring about much improvement (and had its own set of limitations, e.g. limited chroma subsampling support). Furthermore, AVIF is now being supported, so the argument about minimising support for image formats doesn't hold as much weight when they're the ones adding a bunch of them.

Not a requirement of DoH.

No, your company does not have to inspect any of your traffic. If they don't like what they can see in TLS 1.3, chances are TLS 1.2 isn't much better.

No, TLS 1.3 and DoH are genuinely security improvements for the overwhelming majority.

Actually, it seems fairly secure to me.

Can't respond as no evidence is presented...

This is what CAA over DNS is designed to deal with - of course, you need secure DNS for this to work. Not to mention the Certificate Transparency framework which is specifically designed to detect this sort of stuff. And regardless, this is a somewhat risky thing for a nation-state to do - for one, if it's discovered (since changing certificates isn't exactly subtle), you can expect the CA to get blacklisted everywhere, and there'll certainly be questions and speculation on the motive, likely lessening the nation-state's ability to commit the same thing again.

Other than the obvious gimping that Intel's MKL does (CPUID detection, and just being optimised for Intel CPUs instead of AMD), Intel's Skylake-X (and later) support 2x 512-bit FMA units per core (except for Xeon Bronze/Silver and some low end Xeon-W - thank Intel for the confusion), vs Zen 2's 2x 256-bit FMA units per core.
Thus, as you say, FLOPS-wise, Intel's latest has roughly a 2x per-core lead over AMD's latest, if you can use AVX512 (MKL does) and your workload is heavy on FP operations.

Note that AMD's current design scales to 64 cores per CPU vs Intel's latest at 28 cores per CPU (unless you can get their fabled '56-core dual CPU'). If we're talking about top-end CPUs, Intel's AVX512 advantage isn't enough to beat a design with more than double the cores.