He uses the wrong test. Testing on "The Adventures of Sherlock Holmes" is meaningless for developpers: tests should be performed using real usages like "source code of linux kernel" or "mailing list of linux kernel" to have a better balance between code and text.
Even better, it should be performed using a recorded vim session, rather than a full file. The keystrokes you use while editing are not the same as those that end up in the finished file.
But this brings up that some Vim hotkeys are more positional than mnemonic (J-down, K-up), while others are more mnemonic than positional (I-insert, X-exterminate(?)).
This is why I believe that qwerty is the best layout. All applications have designed all shortcuts to be sensible on it. Any other layout is just going to be a disaster and negate any benefits and more during actual use.
You can of course use whatever layout you like and then while ctrl/alt/meta is pressed it switches to qwerty, doesn't save vim users though (or other applications where shortcuts don't need to be prefixed).
I'm not convinced switching from qwerty is that beneficial, I believe (but have not yet tried it) an orthogonal keyboard will do more than any layout will. But I admit that I don't have experience to back that up.
I've been using Dvorak for ~15 years now and the keyboard shortcuts don't bother me. For example, when Dvorak Ctrl+X/C/V is translated to QWERTY, they are in the positions Ctrl+B/I/(period). For shortcuts like Ctrl+C in Dvorak (Ctrl+I in QWERTY), I put my left thumb on Right Ctrl and my left pinky on the letter key.
Two minor problems, though: In Dvorak, V is immediately beside W. Ctrl+V means paste, but Ctrl+W means close window, so care is needed. And, any keyboard that lack Right Ctrl (e.g. the Microsoft Surface series) is an abomination.
The idea would be to optimize the keyboard around English (which you can't remap,) and then to optimize your editor keybindings around the keyboard (which are easy to remap.)
Positional key layout only matters pedagogically. I type dvorak and use emacs + evil (vim keybindings). To maintain the positional correspondence I'd have to swap bindings around and make my setup even weirder, so I just learned j=down, k=up, etc. Muscle memory doesn't care about rhyme or reason.
I wonder how well it would do with Emacs and all of the key chording.
(QWERTY does well enough if you move a Control key back where it belongs by doing away with the useless Caps Lock key. Looking at Workman, you'd need to do away with a redundant Backspace (???) key to get the same effect, but all of the other meta keys and punctuation look sane.)
There's another issue as well. His mapping of difficulty reaching a key isn't really the whole picture. On a conventional QWERTY layout, neither the E nor the C keys are especially hard to reach, but if you had to frequently type them successively, that would be terrible. What matters is not just where a key is in relation to your hands, but also where two keys are in relation to one other.
In grad school, I did a lot of work on the Quadratic Assignment Problem (https://en.wikipedia.org/wiki/Quadratic_assignment_problem). If you model that "key reachability" metric as two-key sequence difficulty instead, you actually get a QAP instance to solve. I built a little toy project that would look at the source text of my dissertation in LaTeX as well as the accompanying C++ source code for bigram frequencies, and I mapped out a flow matrix manually in a similar way to the author here, but including that successive keypress difficulty, and ran my multiobjective QAP solver to generate a range of keyboards optimized for my specific dissertation work.
I did this as a fun little gimmick as part of a sort of "ignobels" within my department, so the results weren't really a thing you could use. To generate a usable keyboard layout, you need to also include a ton of heuristics for things like "put all the number keys together" and the idea that you can treat "a" and "A" as the same letter, but "2" and "@" may make sense to separate, none of which I really properly handled. But I think with some work one could actually formalize the problem of finding a real layout for normal people to use.
Yes, but mid-pack among alternate layouts. Qwerty doesn't even show up. The difference between them is minimal compared with sticking with qwerty.
Other factors to consider would be time-to-learn, hot-key placement, device compatibility and general flexibility. I put my own Python code in your test and workman did much better. Be sure to use several samples when making a determination.
In most of my tests, Colemak was a consistent winner by a small margin.
Agreed, a complete text is quite a different thing from editing text. Recording your typing session would be interesting, it would be interesting to see an analysis on where common typos keep happening.
