To call this rose-tinted glasses when considering how things worked in 1983 is a massive understatement.
A counterexample: in 1983, enter two search terms, one of them slightly misspelled or misremembered, hit f3: "no results", spend 10 minutes trying to find the needle in the haystack, give up and physically search for the thing yourself.
Enter two search terms slightly incorrectly now: no of the time it will know exactly what you want, may even autocorrect a typo locally, get your accurate search results in a second.
When things were faster 30+ years ago (and they absolutely were NOT the vast majority of the time, this example cherry picked one of the few instances that they were), it was because the use case was hyperspecific, hyperlocalized to a platform, and the fussy and often counterintuitive interfaces served as guard rails.
The article has absolutely valid points on ways UIs have been tuned in odd ways (often to make them usable, albeit suboptimally, for the very different inputs of touch and mouse), but the obsession about speed being worse now borders on quixotic. Software back then was, at absolute best, akin to a drag racer - if all you want to do it move 200 meters in one predetermined direction then sometimes is was fine. Want to go 300 meters, or go in a slightly different direction, or don't know how to drive a drag racer? Sorry, need to find a different car/course/detailed instruction manual.
The only thing Windows 10 UI rises to is a paragon of lagginess - and I say that about the UI I generally like, and one that runs on 10-year-old equipment just fine.
There's no good reason for a lag after hitting the "Start" button.
There's no good reason for a lag in the right-mouse-button context menu in Explorer (this was a "feature" since Windows 95, however).
I could go on for a long time, but let's just say that Win+R notepad is still the fastest way to start that program, because at least Win+R menu wasn't made pretty and slow (but still has history of some sorts).
The search box behaves in truly mysterious ways. All I want it to do is bring up a list of programs whose name contains the substring that I just typed. It's not a task that should take more than a screen refresh, much more so in 2019. And yet, I still have no clue what it actually does - if it works at all[1].
I agree that a lot of the use cases back then were hyperspecific and the software were drag racers. However, much of what he talks about is productivity tools. I believe those fit the same description. I occasionally work with many different screens using a TN3270, some of which look very different and have very different purposes, however they have a common interface with similar keystrokes. This makes navigating even unfamiliar screens a breeze. He talks about is the commonality of keyboard language compared to that of GUI and I think that is an excellent point of his.
So to some degree that's preaching to the choir around here; I still use emacs extensively and adore it, but I'd also never wish it upon anyone who doesn't value work efficiency over low cognitive load and nice aesthetics. In my experience, at least, that's most people.
In light of that, I think it's less that we've "lost" keyboard-driven efficiency as much as knowingly sacrificed it in favor of spending UI/UX dev time on more generally desired/useful features. The nice thing about being the type of power user who wants more keyboard functionality is that you can often code/macro it yourself.
Part of that was the widespread use low-resolution, high refresh rate, zero-latency (CRT) monitors, and the use of hardware interrupts instead of a serial bus for input.
A counterexample: in 1983, enter two search terms, one of them slightly misspelled or misremembered, hit f3: "no results", spend 10 minutes trying to find the needle in the haystack, give up and physically search for the thing yourself.
Enter two search terms slightly incorrectly now: no of the time it will know exactly what you want, may even autocorrect a typo locally, get your accurate search results in a second.
When things were faster 30+ years ago (and they absolutely were NOT the vast majority of the time, this example cherry picked one of the few instances that they were), it was because the use case was hyperspecific, hyperlocalized to a platform, and the fussy and often counterintuitive interfaces served as guard rails.
The article has absolutely valid points on ways UIs have been tuned in odd ways (often to make them usable, albeit suboptimally, for the very different inputs of touch and mouse), but the obsession about speed being worse now borders on quixotic. Software back then was, at absolute best, akin to a drag racer - if all you want to do it move 200 meters in one predetermined direction then sometimes is was fine. Want to go 300 meters, or go in a slightly different direction, or don't know how to drive a drag racer? Sorry, need to find a different car/course/detailed instruction manual.