The deal with live and/or dynamic streaming is that the simple HTTP protocol doesn't have any mechanisms for it built in (versus something like RTMP). So there has to be intelligence on one end or the other. It's actually better to have the client have the "brains" so to speak, and make the web servers dumb. This is good for scalability.
Microsoft, Apple, and Adobe all now have pretty solid streaming-over-HTTP solutions where the client knows how to ask the server for different resolutions, bitrates, and most importantly different time segments of a video stream. This makes them very bandwidth, cache and CDN friendly solutions. Microsoft and Adobe do require a module server side to "chunk" a big file up into segments, while Apple has you pre-chunk files and use a totally standard HTTP server. But otherwise, the intelligence is all on the client plug-in, and you can put proxy caches or CDNs in origin fetch mode into the mix with any of the solutions to scale things up very rapidly.
The traditional connection-oriented streaming protocols require dedicated servers and simply don't scale very well. You have to pay an Akamai or Limelight big dollars to run a large number of streams to a huge audience. They have tens of thousands of servers to handle that sort of thing.
The relatively new HTTP-based options mentioned above actually work with the huge HTTP caching infrastructure already out there on the web in organizations and ISPs, as well as the huge HTTP caching infrastructure offered by CDNs (which typically offer lower prices for HTTP delivery than connection-based streaming).
Apple has even submitted their Live HTTP streaming solution to the IETF for consideration as an open standard (although I suspect there are patents to worry about from Move Networks who pioneered this sort of thing).