The last gov team I was on had trouble with the uswds icon set. There didn't seem to be a way to import them as a font rather than as separate svgs. We noticed though that the icons were roughly based on Material Design icons, so we used the Material Design icon fonts instead and they were close enough. There were still a few icons that didn't map over, but we found some others within the new set that sufficed.
In HTML when used as images with the IMG tag, SVGs and bitmap images have a direct concept of ALT attribute for accessibility to screen reading. Font glyphs do not. You can add aria- tags around font glyphs but you can't add/set those in just pure CSS and so most icon font libraries don't bother. It also doesn't help that the most common tag for adding icons from icon fonts is the I tag (from ancient HTML for Italic, though EM is the preferred tag) which not only doesn't naturally support things like ALT tags it is even worse for accessibility by implying the wrong semantic meaning ("there are italics near here"? But there aren't).
Consider an icon font where "E" is a little "edit" pencil- to a screen reader it just looks like an "E".
Of course you could just put `aria-label="edit"` on its container the same way you would an SVG.
The icon font is also a problem if the font doesn't load and the browser uses a fallback, now you have a weird "E" in the middle of your document. They're harder to get aligned just right in my experience as well.
Someone's probably done this already but it would be cool to have an icon font that uses ligatures- so you'd type "Edit" and it would turn into the Edit icon. Wouldn't solve the other issues but it would be neat.
Font Awesome 5+ supports ligatures in that way, though my understanding is that it was intended for ease of use in design apps like InDesign more than for accessibility, but I suppose it can help accessibility too. (Though Font Awesome suggests SVGs over icon fonts for actual usage on the web.)
I would expect modern icon fonts to exclusively use the Unicode Private Use Area. Fallback fonts would then not have glyphs for these code points. Screen readers would hopefully ignore them.
Screen readers ignoring them is a problem when it is UI the user needs to interact with. How does the use know that U+E9AF is the Edit icon they are looking for versus say maybe U+E9AE is the Delete icon?
They don't. That's is why icon-only items (links, buttons, …) must always be explicitly annotated, using aria- attributes. You can do this with any icon technology. You wouldn't annotate the icon itself.
Beyond the accessibility problems, Icon fonts don't tree-shake very well and subsetting them is complicated and requires dedicated tools. Bandwidth may seem cheap/free in many cases, but SVG-based approaches can tree-shake down using ordinary web platform tools like Webpack to just the used SVG curves of the icons needed specific to a page or app and that can save you megabytes compared to most icon fonts.
One of the key notes in the bottom table on that page is "Auto-Accessibility" and the JS libraries with SVG icons provide better accessibility out of the box. Most of the document you linked is stuff you need to do manually by default when working with web fonts.
