I was manly talking about icons, but not logos. Icons usually only have one color—which is often the same color as the surrounding font color. If your icon is only a single <path> (most good icons are) then you can color them with:

    svg { fill: currentColor; }
    .parent { color: var(--text-color); }

When you use dark-mode the color of the svg path should change with the text as long as the author changes --text-color in a dark-mode media query.

    @media (prefers-color-scheme: dark) {
        --text-color: wheat;
    }

I don’t know about the size, but I suspect that if any the difference is negligible. Most of my icons are a few hundred bytes uncompressed. And I usually put them in a sprite which is usually well under 50 KiB uncompressed. I don’t know how large font icon files are, but I suspect they are not that much smaller that it makes a difference.

> Svg is also often much larger than a font file, especially one that's subset.

Subsetting is where SVG shines, though.

For icon fonts, you can much more easily subset SVG icons than a font file. Font file subsetting needs dedicated tools like font editors (with Icomoon being a common choice these days) and often manual maintenance/upkeep, whereas SVG tree shaking is a natural part of any web bundler (webpack, etc) and automatically adapts to your icon usage and tools in your web bundler such as bundle splitting/lazy loading.

The Fort Awesome JS libraries behind Font Awesome's SVG icon fonts reduce things further from SVG XML files to tree-shakeable ESM files [EcmaScript Modules] that include just a few pieces of metadata and the lone important path text (sticking to a single SVG path per icon), then build the SVG DOM at runtime (as VDOM in the case of the React library), including making sure it follows fill: currentColor to pick up the text color. Minified and tree-shaken by most web bundlers the ESM files are very competitive with any other font format and the convenience wins of automatic subsetting by web bundler are hard to match.

I use Calibre for font subsetting, usually for use in ebooks, but I've used it for a website as well. The only gotcha I've found is that Calibre doesn't recognize css content attributes (`div.icon{content:"source:"}`), and that font names need to be correct. This is pretty trivial to get around, and generally only needs to be done once.

I've never used webpack or any other bundler on any personal website I've written, nor have I ever used react or other heavy frameworks (I used jQuery when I was in school). Perhaps these are useful on larger websites, but I prefer to avoid scripts in general, with the sole exception being scripts that parse a data source to generate a page client-side (most pages on my system are static, so I don't even have php or such installed). To me, automation means I make changes to the html on my server and reload the page.

SVGs are still often better subsetted raw ("unbundled") in that case both for local development and on HTTP/2+ servers. Things are slowly moving back away from bundlers/bundles which were mostly about getting the most out of HTTP/1.x tradeoffs most of which either no longer apply (because changes in browser caching rules for privacy reasons) or are mostly obsolete concerns (with HTTP/2+).

You aren't going to get easier subsetting in a modern browser than a folder full of SVGs and the browser only pulling the URLs it needs as it needs them rather than an entire bloated icon font format all at once up front. No need to double check that Calibre has got the right font subset from your CSS or to open Calibre at all, just upload the folder of SVGs and let the browser "subset" it, in the classic ways of HTML going back to its origins. Even less "automation" than Calibre.

> I don't expect logos in the text to fade into the background.

You can use @media (prefers-color-scheme: dark) { ... } in the style inside the .svg and browsers render it accordingly in dark/light mode. But yes, not being able to set the color from the page CSS is annoying.