"Apple and Microsoft each have a single sound server that does both desktop and pro audio"
This is not strictly true for windoze as I pointed out during the discussion at LPC. While "desktop" audio applications make do with the standard windoze audio system, professional audio interfaces all ship with ASIO/ASIO2 drivers for a variety of reasons - not the least of which was the inability of the standard windoze audio system to provide low latency performance (in fact, over the years there have been other APIs besides ASIO). Vista may be different in this respect but it has other audio-related problems.
MacOSX has CoreAudio which, on the face of it, does integrate the consumer and pro requirements under one API. However, digging deeper one realises that it is probably closer to the pro side of the equation, with added features allowing seemingly easy access for consumers. At least at first glance CoreAudio is closer to JACK than ALSA/PulseAudio.
"... but nobody at the session seemed to have much interest in that direction for Linux"
It's not that we're not interested - the ideal solution is to have one sound system to rule them all. The problem is that the requirements of desktop users and pro audio users are much more divergent than many people realise. Getting a single audio system to satisfy all usage constraints while still performing efficiently is very difficult. As an example, desktop/laptop users are primarily interested in lowering power consumption, but doing this while maintaining a low latency audio system
The other issue is that JACK is much more than just a route to audio hardware. It implements extensive and flexible inter-application audio and midi routing - something PulseAudio doesn't do simply because it's not a feature required by desktop users. JACK also gives synchronous operation of all connected applications and provides sample-accurate synchronisation, but again these features are not required by the average desktop users. Oh yes, network audio *does* matter to pro audio users - and for that we have netjack.
What this boils down to is that JACK and PulseAudio are working in different problem spaces. They are optimised for different situations, and trying to make one also provide the functionality of the other will only result in a system with suboptimal performance.