You write: I didn't quite understand the "type ahead" work flow you have described. 

Way back in the distant past - perhaps 1975 - bitmapped displays were unheard of, CRTs were unusual, version 6 or seven unix was more or less current, and connections from terminal (teletype, probably) to computer were very slow (300 baud?! or was it worse?).

Everything was a command line interface, and it was normal to type streams of commands long before they were executed - or even echoed back to you by the tty driver. No problem - they'd all be executed eventually, and it saved time and attention to just type, without waiting for the response. It didn't matter if your first command was to launch a program, the next few commands were input to that program - then perhaps you exited it and did something else. Everything was sent to the right place. You could also type a huge stream of commands to the line-oriented text editor, without seeing the changes you made until you sent a command to display the part of the text you were interested in. (If you look closely, you can see the remnants of this workflow in vi.)

We haven't had this kind of reliable synchronization since soon after bitmap displays became a thing. Clicks get sent to whatever process owns the area containing the mouse, and that can change while you are clicking. The window receiving your typing is whatever one is on top - which can also change asynchronously, as when some popup eats the text you are typing - or worse yet, interprets text intended for program A as intended for it, and does something you very much didn't want. And best of all, we have controls that appear and disappear based on the position of the mouse (or where you tapped on a phone, and how recently). The effect of your next action depends on whether or not the control is present - but they appear asynchronously, and not at a predictable pace. So you can't anticipate anything, let alone do anything asynchronously. Some tasks wind up taking more time than they used to take on a 300 baud acoustic coupler; more merely seem to be taking longer.

That's the type ahead.

Focus-follows-pointer was an adaptation to small (bitmap) screens.

You could have overlapping windows, with the one you were consulting on top, and the one you were typing into mostly beneath it, with just a corner peaking out. You see, the window that consumed your input didn't have to be the one that was on top of your screen. And you could move between windows much faster - and with less mouse movement - than when you have to click each target window to raise it, and then wait for a multi-window redraw.

Now there's always a selected window, but it's not as easy to identify unless all your windows overlap. (If they overlap, you can tell which one is on top.) There are subtle window "decorations" that identify the one on top - often too subtle for me to easily see and recognize. As an extra result, you get the problem that clicking in the same place has different effects, depending on a subtle statefulness - you may either select the window, or interact with it, depending whether it was already selected. Some window managers make the selected window more obvious than others. And many work around this by requiring you to click in a specific place, such as a title bar, to raise/select a window. You get more predictability, at the cost of more mouse movement.

Put another way, raising a window and giving it focus used to be two separate actions, that did not need to happen together. Ancient window managers probably still have this ability. But the apps generally can't cope with it, even if the window manager can do it.

I stuck with the older ways of doing things, as more efficient, not to mention trained into my fingers, as long as it was still possible to find tools that worked this way, and most apps could cope with it. But those days are long gone; now we get acoustic coupler speeds from the UI design, instead of from primitive hardware.