Everything else is either an attempt to do less work or an attempt to shape user experiences for your own goals.
Threading requires two data elements per message, generated at the time of message creation: a unique-enough message ID, and the parent message ID. The client needs to have a method of storing 1 bit of state per message, either locally or on a home server. If messages have a timestamp, then a high-water mark is a useful heuristic. If the messages have required subjects, tags or topic groups, you can significantly improve both performance and user experience.
Usenet shall be resurrected, time and time again.
On top of that is further organisation: non-HN feeds are batched together in a single display, but HN often produces more than a screenful (~70) of unreads, so then I have hotkeys that filter out alphabetic subsets: A-G, H-R, or S-Z. That normally suffices to avoid any scrolling, but when I haven't been following RSS for several days, I also have filters that further limit to a single day, either 1, 2, 3, or 4 days ago.
Although the underlying data is kept chronologically indexed by newsboat, and I can always refer to it that way (frex the concrete splits AG/HR/SZ were determined by querying newsboat's SQLite instance) it by no means prevents layering a myriad (well 20, not counting newsboat's ad-hoc command line filter interface) of other ways to organise on top.
PS thank you for reminding me to finally look up how to turn off threading (View»Organise by Conversation) in the mac default mail proggy!
Generally it means "select the material and the ordering in the manner that maximizes revenue for the platform's owners". I'd call that a sensible (if morally questionable) strategy for the owners.