try it yourself next time

@font-face
{
font-family: Shiny;
src: url(http://server.example/Shiny.eot);
src: url(http://server.example/Shiny.ttf) format(truetype);
}

h1 { font-family: Shiny, sans-serif; }

IE will parse the first line, understand it, and download the file. It will not understand the second line–it will try to download a file from “http://server.example/Shiny.ttf) format(truetype”–resulting in a 404, so the first file will get used.
Safari will parse both lines, the second will override the first, and thus be used.

If this method doesn’t work, you can always use conditional comments to provide one src to IE and a different one to other browsers. This way you don’t have to always have the same pair of font names in all your CSS.

Instead of something they know damned well IE isn’t going to support and even if it did, in IE9, we’d still have to wait out the fall-off of IE6, IE7, and soon, IE8 to negligible levels.
Why even bother?

I guess a similar question can be asked of innovations like border-radius, text-shadow, css transitions and really any browser innovations.

Font embedding degrades gracefully, and as I demonstrated in this article, the two forms (TT and EOT) can sit side by side. So, I’d argue that as of wide spread adoption of FF 3.1 (some time in the next 3–6 months given FF upgrade rates), you’ll have font embedding technologies in IE (any version), Firefox, Safari (including iPhone), and potentially, Chrome (it seems the webkit version of Chrome was forked off some time ago, so there’d be work to be done) — covering just about every browser on the planet.

I can only speculate as to why Safari and Firefox implemented embedding with non EOT fonts. But here are a few ideas

1. From a technical point of view, I support for EOT would be non trivial to implement. Obviously, both browsers already support TT fonts, so implementing downloadable TT fonts would clearly be far far less work.
2. As open source projects, given the current status of the EOT specification, under the licenses under which one or both of Mozilla and Webkit are released, it may not legally be possible to have open source software that supports EOT decoding. This has certainly been the case with native support for some audio and video formats in OSS.
3. From a strategic legal POV, supporting DRM for fonts directly in the code base might be a slippery slope. Would it open the prospect that owners of other kinds of IP use support for DRM with respect to fonts to argue that browsers should now natively support DRM for all IP. Given the aggressive approach to both reactively and proactively defending their property rights (real, and sometimes imagined) of for instance the recording industry, do you want to give those folks an inch when it comes to dictating the content policies of your browser?
4. from a business strategy point of view, I imagine companies on the whole don’t typically support the efforts of their competitors to create industry standards.

Al as I said of these are speculation pure and simple.