First, about fairness. I don't think it would be unfair to very many people on "other" OSes because Apache runs at least on Unixes, Windows, and Macs. Anyway, those few platforms not supporting Apache are likely to be less suitable for running a web server. Also, I doubt that those who develop for, say, aolserver are that concerned about compatibility with Apache, so it's not really a fairness issue, IMHO.

I think it's about smartness. You should pick the most suitable platform up front, for your definition of suitable, then go from there. One of the coolest things about Apache is mod_perl. Having perl embedded into the server and the ability to access all the server API is cool. You could argue that aolserver has the same thing with Tcl, but who really wants to program in Tcl? ("Will dis Tcl for XP" the T-shirt would say :) (I don't know what the alternative is with ISS, but I've heard of ISAPI, so there obviously is some way to access their native API. In any case, you'll still be tied down to that platform's API) Also, if you prefer Java over Perl, you can still go with Apache because you have Java servlets, which are the equivalent of mod_perl but using Java.

Probably what it comes down to are things like: can you find/afford developers who know your platform, who know your programming language, can you convince management to use this platform? Platform including language and hardware, not only the http server.

Still, I have to wonder about a DBI-like wrapper around all HTTP servers. Maybe it's a nice idea. But, what language do you write the wrapper for, Perl? What if this Java thing really takes off, maybe you should've written your applications in Java so you could find cheaper developers. Then what good would programming for the generic http API have done?

(Like you, I'm obviously just giving some ideas to consider. Maybe they're not the best ones.)