The blit used a multiplexed data stream running down a serial cable, StarLan or latterly Ethernet. It was not that different to (later) running SLIP down a serial line with multiple IP sessions breaking out to various programs.
The novelty you're getting at was not having multiple windows, but having a way of driving sessions down a communication stream. The only difference with the blit was that it was driven down a single serial line, but when you think about it, there is absolutely nothing special about a serial line, it is a bi-directional communication path with flow control (if set up properly), and the only thing different about using RS232 and, say, IP over SDLC down a leased line was the speed. The multiplexing was part of the layered software that sat over the communication path.
It wrapped the multiplexing into a user-land program on the host, and the downloaded firmware in the blit (5620's had to download the protocol handler as part of the initialization, 630's had it in persistent storage so that it was available immediately). Without that protocol handler, both 5620s and 630s were just big, expensive terminals with large screens (and you could use both like that if you wanted). Unlike, say, SLIP, the multiplexed sessions appeared on different pseudo-terminals on the host as if they were simple terminals, but mpx/Layers did also have a primitive file handling system to allow things like the jim editor to down and upload files to be edited locally.
I don't know for certain, but I think that Rob Pike et.al. were playing around with the experimental Multiplexed Files on UNIX Edition 7, and then the AT&T STREAMS environment on later UNIX versions, to move the multiplexing away from user-land, and into the terminal stack of the OS.
But I left the AT&T owned company before I got to play with blits over anything other than serial lines, although I was involved with a StarLan implementation, and also with some of the other AT&T networking products like RFS. I was offered a job at UNIX System Laboratories (USL) at one time, but they couldn't make it sufficiently financially attractive.
But getting back to your last point. You say why not add it to the shell? Well, UNIX has always had ways of doing what is happening here, without having some monolithic single program, so it is probably against the UNIX way of including it in the shell.
And I can't say that after trying to follow the YouTube video, that I would actually find it that useful myself.