No it doesn't. SIV is almost as fast as AES-GCM when implemented with AES-CTR and GMAC (in my benchmarks on x64 and Apple M1). It requires two passes to encrypt but on the second pass the packet is in L1 cache already.

EDIT: nonce misuse resistance is IMHO a robustness thing. Yes large nonces give you similar bounds, but there are numerous banana peels like cloning VMs, live migration, IoT devices with bad PRNGs, incorrectly implemented concurrent counters, concurrent counters that work fine on x64 and fail on ARM, etc. that can cause nonce reuse.

Sudden death from nonce reuse just give me the willies. Kind of a big footgun.

I honestly don't care if you want to use straight SIV, AES-GCM-SIV, or some hand-rolled in-between SIV. SIV is fine. But it's not GCM.

To your additions to the comment above: the point of large nonces is that you always just use random nonces; you retain the RNG point of failure (which you almost certainly have anyways) but you don't have the "concurrent counters" problem anymore, since you're never going to use counters as a nonce (or, if you do, you do so in addition to a 128 bit random nonce).

A nice property of the XChaCha+Blake scheme proposed here is that Blake doesn't have any nonce dependency at all, and most of the terror of nonce misuse comes from how the MAC deals with repeated nonces, not how the underlying stream cipher does (though, obviously, a reliably repeating nonce gives you a pretty devastating confidentiality failure).

That may be true, but does it really matter? The name of the cryptosystem seems pretty irrelavent unless you have some compliance checkbox to check.

It makes the "SIV fixes this" a non-sequitur. "SIV fixes this" is like saying "not using GCM fixes this" which (for avoiding a problem in GCM) is somewhat uninteresting.

Actually you're right. I was equivocating because there are SIV modes that use GMAC, the MAC component of GCM, for its performance benefits on hardware.