"if they ever release it" is a perfectly valid reason to move away from Screen.
But since you're asking for technical reasons:
* vertical splits in screen are unusably slow given high throughput.
* tmux's default key bindings actually make sense, and if you don't like them you can change them. screen only lets you change a few of the bindings; there's no way to make copy/paste match something like Emacs style. I used and loved screen for years, but I never used copy/paste because I just couldn't internalize the bindings. tmux made sense on day one.
* screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
I feel like your critique of screen's customization is a little inaccurate; you said that "screen only lets you change a few of the bindings," but actually, copy/paste are the only ones it does not let you change.
I agree that they're rather unintuitive. As a vim user, I have less cognitive dissonance, but I do dislike the way that the bindings are almost vim. I think you did yourself a disservice, though, by never figuring out copy/paste at all--it's quite usable once you get the hang of it.
I think that hand-wringing over using suid for shared sessions is premature; while I agree that any experienced sysadmin should flinch at the overall concept, it's important to remember that the screen binary itself is still writable only by root, and that while you run it with setuid, the resulting shell child process is not run as root. So, to the extent that there are no "screen injection exploits," running it with setuid is a non-issue.
I disagree, since we're talking about open source, here. More to the point, this is a marketing reason[1], not a technical one.
screen actually requires suid for multiuser support, which is atrocious, while tmux simply communicates over a socket, and whoever has the permissions for the socket can join the session.
This is an important distinction, though, to me, it doesn't make one better or worse than the other, in general, just for specific circumstances. This kind of detail is why I crave objective comparisons, like the OC, though perhaps from different motivation.
[1] Which I, personally, don't consider valid, though I wouldn't suggest it isn't to you.
setuid I could handle if it were just that, but screen reimplements its own internal permissions model, while tmux simply uses unix permissions, which everyone already understands. Composability wins.
That's exactly my point. This is neither categorically good nor bad. It doesn't reinvent permissions gratuitously, but, rather, as a way of increasing flexibility.
It allows per-window permissions and fairly arbitrary permissionsetting, for any user, without resorting to groups (the membership of which a regular user does not control) or universal permissions.
We're planning on follow up posts to this one, hopefully with screencasts to help visualize it better.
I was so happy, because I finally thought that this would be a direct comparison of screen and tmux from someone who was very experienced in one or the other.
But, no. It was someone to whom even common features between the two were novel. I'm not saying that this is a bad article or that you shouldn't read it or that the author shouldn't have written it, but damn it, I've been using screen for years, and everywhere I turn, I see tmux, too!
But so far, the only thing anyone has been able to offer in terms of concrete differences is "tmux can do vertical splits," which will be true of the next big version of screen as well, if they ever release it.
I am officially declaring shenanigans on anyone who blurts "tmux is better" without linking me to a @#)&@#%ing objective and thorough comparison of the two apps that actually makes it seem like tmux is worth using instead. Even the very first result on Google comes up with nothing more than "tmux has some kind of client/server thing," which seems exactly the same as screen -X.
Edit: I upvoted the article to solidify that my problem is not with it, but with the context in which I read it.