1) the delay is part of the design of our P2P multicast system. the delay is necessary to give subscribers an opportunity to obtain pieces of the stream from their peers. the NetStream.multicastWindowDuration controls how long a subscriber will try to obtain the data, after which it gives up and the data is just declared missing. the window limits the amount of jitter you can expect (the default is 8 seconds). decreasing the window can decrease latency/jitter, but will also decrease reliability (that is, increase the number of gaps/glitches you'll see in the stream). if you make the window very small, there might not be enough time for group to do the necessary work to propagate the stream beyond a very small number of subscribers.
2) the group automatically tunes itself trying to reduce the propagation latency and increase efficiency and sharing fairness, by building a number of parallel "push" spanning trees through the group. in a completely stable group where nobody joins or leaves, the propagation latency can eventually get very short, but groups are never really that stable. any disruption to the push mode will require falling back to the default pull mode to fill in a missing piece, and again that's what you need the window for.
note that in an N-to-N way conversation (example: 3 party conversation, everyone's streaming simultaneously), it's actually more efficient to build your mesh out of DIRECT_CONNECTIONS streams. with P2P multicast everyone needs to receive each stream, which means each copy for each peer needs to come from somewhere (which means the other peers). so on average the bandwidth would be exactly the same, except that the multicast stream has additional overhead associated with it, which isn't present in DIRECT_CONNECTIONS streaming.
for more about how the P2P multicast system works, please view Matthew Kaufman's session from MAX 2009: