It has to do with our multiple layers of caching. While the entire response to an API call is cached (as expected), we also cache individual components of the response (such as each stream object). So when we rebuild the /streams response, we fetch the ordered list of streams by viewer count fresh from our streams service, but then check to see each of the stream objects in that response to see if we have a cached copy pre-rendered and if so we use that instead. That cached copy can be out of date, and have higher or lower viewer numbers, causing the ordering to appear broken. I hope that explains this strange behavior!
tl;dr - yes its for performance reasons.