For example, right now I can issue a shell command that lists cpu utilization by process (top). I can even have that command autorefresh, showing me changes in real time. But to do that it takes over the shell. It'd be neat to think about a shell where I could issue a top command, then command displays and exits, giving me a shell prompt again. But I have the option of asking the shell to update the old output every N seconds.
Yes, I could in i3 spawn a new shell and just keep top running in it. And maybe in the long run that's the better interface. But doing that screws up my carefully constructed window layout.
I guess what I'm saying is that we have two interface paradigms: the gui, and the command line. But interfaces like Jupyter and Mathematica show that there are middle grounds between those two extremes, and that middle ground is interesting.
An alternative is Emacs, which will give you shells and windows and splits and somewhat-interactive documents (org-mode) and has some support for images. If you're ready to sacrifice an hour per day to Emacs configuration for the next twelve years, it will do your biddings eventually...
To me this is off. With a tiling window manager I don't have to "carefully construct" a window layout. That's the window managers job!
Then the issue becomes how well bash output takes advantage of Jupyter. Research forthcoming.
I find the conclusion of the article totally off the mark. The author seems to not understand that problems begins with multimedia support and other "gimmicky" stuff (as he puts it). You want video? Then use your terminal to launch a video player. A tiling manager is precisely perfect for this (I wonder why you switched to i3 if you don't know that, btw).