re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.
I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.
Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.
Every modern graphical editor I'm aware of lets you jump around in tabs/windows/panes etc. exclusively with hotkeys.
I don't know why people keeping talking about clicking around. They are all completely operable without resorting to clicking. Maybe not with IDEs, but with VS Code / Sublime / Atom, you don't need a mouse for anything I'm aware of.
(buffers can be files, configurations panels, terminals, applications, whatever really)
But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.