Module vs WFL library as JS in theme. Discuss...

Oh dear, this is certainly a loaded question ;) I'll naturally have a few biases but a few of my thoughts on the disadvantages section.

No need for .fontinfo files

That would probably be a huge +1 for most people ;) I myself don't find it hard to create the files but most don't want to get into that.

100% detached from database (all in code = better version control, easier deployment)

While I agree it is detached from the database, I don't necessarily agree on the better vcs, deployment part (I would mostly say they are equal on that front). Since the fontinfo itself is a package containing the necessary information, I've added it to my repositories and been able to deploy it without any issues (its still code or font files) so packaging it up into vcs is a non-issue. For deployment, I suppose enabling the right font package might be what you're referring to though that can be resolved either with placing the conf in settings.php (or a version that can go into vcs) or in a module update hook (which can def. go into vcs).

Font requirements can be self contained within a theme - greater portability (within reason - access keys etc)

For most of the projects, I've included a set of font packages within a theme so the end-client can select from them (which I'll get into at the bottom)

Choice in specifying which version of the library to use

Yep, absolutely. I went from putting in to get the latest version of the library to using a specific version for cdn purposes (which means my version of the library may be out of date - in fact, it actually is right now as the library is at 1.4.10 while I am serving 1.4.8. Should make a release of it in the next few days).

More options through JS configuration (timeouts, contexts etc)

Also true. I debated between having more options on the settings page (and just using a set of defaults that seemed to work well). I opted for the latter though I can certainly see a usecase for the former.

No delay between the library supporting a new font service and the theme being able to use it (in contrast, presumably we'd have to wait for the module to add support through .fontinfo files?)

Semi-related to #4 but yes, you are right on that front.

The big use-case that this module solves is the ability to select which font package(s) get served for the site. My history on this is that I was involved a fairly large set of sites where they wanted to have some level of branding between all the sites while still allowing some level of customizability in look/feel. Part of the customizability was typography. So the designer created a set of font packages (some of which included fonts that were created by the institution so they had to be included within the site) that worked well with the theme(s) and the client then had the option to choose from these packages on which one they wanted to use on the site. So the big advantage in this module comes when you have a set of typography presets that work well with the theme and you want the client to have the ability to change between them. The font-your-face integration came much later (and I'm really happy with how the two now play together).

So if you're ok with losing that (and I imagine most folks likely are since most sites will be built with one theme and typography in mind) AND you can load the js directly within your theme to get the consistent experience you want in loading the fonts, I would suggest definitely suggest foregoing using any such modules and going ahead with that approach (because you know what you're doing at that point :)).