Specifications can have bugs or deficiencies, and in those cases diverging from the specification can provide a net win. Also note that in this case the specification considers the cross-origin restrictions optional, not mandatory.

In this case, prohibiting the loading of fonts from other domains (unlike img, video, audio, CSS, script, etc) seems both unnecessary and harmful.

As I understand it, that bit of the specification exists for the sole purpose of mollifying large commercial font foundries, who consider themselves the only source of usable fonts, and who consider this particular point an existential threat.

True. The fiasco is more or less around the issue of discovering the root cause of why my fonts weren't displaying properly in Firefox, when they did in webkit.

Loading fonts from another domain requires that domain to explicitly whitelist your use as acceptable, using a CORS (cross-origin resource sharing) policy.

    ~$ GET 'http://fonts.googleapis.com/css?family=Muli:300,400' | grep src:
      src: local('Muli Light'), local('Muli-Light'), url(http://themes.googleusercontent.com/static/fonts/muli/v4/zR-6QGMCFX5j-6nbH_HpIQ.ttf) format('truetype');
      src: local('Muli'), url(http://themes.googleusercontent.com/static/fonts/muli/v4/BfQP1MR3mJNaumtWa4Tizg.ttf) format('truetype');
    ~$ HEAD http://themes.googleusercontent.com/static/fonts/muli/v4/BfQP1MR3mJNaumtWa4Tizg.ttf | grep '^Access-Control'
    Access-Control-Allow-Origin: *

Google uses "Access-Control-Allow-Origin: *", but another site could easily provide customer-specific URLs and use "Access-Control-Allow-Origin: paying-customer.example.com". This restriction on @font-face exists for exactly that reason, which explains why browsers other than Firefox have intentionally not implemented it.

I wonder what it would take to get Mozilla to reconsider that decision? This doesn't seem like a point worth diverging from other browsers on; in this case, the other browsers got it right and Firefox got it wrong.