This is complete nonsense, because by providing pagination parameters (offset and limit), the user of such an API endpoint has to assume that the returned list is sorted in some way. And since there is no request parameter for changing the sorting, like for example on the followed channels endpoint, a static sorting of some kind has to be assumed. However, the list doesn’t seem to be sorted in any way. And if it is, then the sorting is completely useless and works against pretty much every consumer of the endpoint, since they are most likely (definitely) expecting a list of streams sorted by viewer numbers, just like on the overall streams API endpoint.
Sorting on the client side, like you are suggesting, is an absolute no-go, especially on any network related data retrieval, or do you also fetch every row from a relational database query response in your own native applications and do the filtering and sorting afterwards? Probably not, because that would be totally ridiculous.
And by the way, the followed streams list on the kraken API has been sorted by viewer numbers ever since I’ve started building my Twitch application in 2013. And now, all of the sudden, it got changed. If it was an intended change, then a sorting parameter has to be added by the API devs for the reasons stated above (not to mention that Twitch is introducing a breaking change here for whatever reason), and if it was an unintended change, then we all have to wonder whether Twitch even still cares about its deprecated kraken API, which is weird though, because the new helix API namespace is still a total disaster.