But the flat thread model is still limited, particularly for complicated topics even a thread starts having the same problem as a channel where there is too much going on; have you thought about tree-structured threads, or some way of branching threads when there is a bunch of discussion happening on different topics?
I haven't really used Slack much, but one of the other places with lots of space for improvement in Flowdock was search, and Slack does seem to be investing there significantly, and I hope Zulip is as well.
With Zulip's existing model, you can always fork off a side discussion by just starting a new topic, if appropriate adding links in one or both directions (and people pretty naturally do that when it makes sense to). Some Zulip users are fans of a convention to name a topic "original_topic.d" for a "digression" off a topic, but I think it's a much better approach to choose a topic that more directly suggests what the forked conversation is about.
(And I agree search is really important! If you're having lots of high-value conversations in a tool, it needs to be easy to find them later. Zulip's powerful full-text search has been praised as a lot better than Slack's since our very first prototype version of it. I think a big part of the reason is that the threads provide the context to make it easy to find the rest of a conversation. But we're always working on making it better).
If you're looking for a product built by top MIT engineers who spent years thinking about how to make chat actually productive, check out Zulip. I'm one of those MIT engineers, and I agree that Slack is a huge waste of time, for precisely the reasons you describe (here's our attempt at explaining how Slack wastes your time: https://zulipchat.com/why-zulip/, and how Zulip solves those problems; there's more on our homepage).
The fact that Slack is, in most organizations, either very low-traffic or a waste of time is why we don't market Zulip primarily as "open source Slack" -- it really is a different product, designed to be amazing for a large, distributed team doing a lot of communication, without things becoming overwhelming.
If you don't believe me, read this awesome cartoon by one of our users: https://twitter.com/b0rk/status/986444234365521920
(As another reason for Slack's success, I'll also add that a lot of "Slack clone" products are pretty buggy; everyone underestimates how much work a high-quality chat experience is. Check out https://zulip.readthedocs.io/en/latest/subsystems/markdown.h... and https://zulip.readthedocs.io/en/latest/subsystems/events-sys... if you want to learn about the complexity of a few of the more interesting challenges.)