The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.
In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.
Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol more carefully.
I hadn't looked at SCRAM before, but from at a quick glance it looks like the only thing preventing an attacker from brute forcing weak passwords from nothing but a passively captured login session is an expensive-to-compute hash function (PBKDF2). It isn't as bad if SCRAM is wrapped in an SSL/TLS session with associated certificate, but if you really trust nothing has MITMed (i.e. incorrectly trusted certificate) or otherwise broken TLS (from the perspective of the client authenticating the server), then why not just send the password directly through the tunnel (from client to server), and avoid extra complexity?
Note that capturing a login session is generally a much lower bar than obtaining the password database, and SRP does not allow brute forcing even trivially weak passwords from just a captured login exchange. (As long as there aren't any huge breakthroughs in quantum computing or other discrete logarithm algorithms.)
All that said, you are correct that SRP or other low level single-connection authentication mechanisms do nothing for the cross-party authentication issue discussed in the article.
But they most certainly are not selling a 4 year old computer.
They actually are. As of this writing, the non-retina Macbook Pro is still available for sale on Apple's site. Go to apple.com, click Mac -> Macbook Pro -> Buy and then scroll about halfway down the page. That model, which is being sold for $1099, hasn't been updated since June 2012, though it did have a $100 price cut in July 2014.
I haven't yet decided, though I am leaning to keeping the 5S. My existing phone, with a new battery, would probably have at least 2 years of useful life left in it. The SE doesn't really have anything in it that is all that compelling to me compared to the 5S except for Apple Pay support, but I don't shop at Apple Pay locations very often. If my phone were a 5 or 5C, it would be a different story, but the 5S has aged remarkably well and holds up well to Apple's more recent offerings.
Possibly useful if you have old Apple ][ disks laying around:
Many years ago I graduated and lost access to Apple ][ machines at school, but still had a bunch of floppy disks for them.
Then just a few years ago I happened to stumble across a tool called disk2fdi http://www.oldskool.org/disk2fdi for MS-DOS, that can read Apple disks using IBM hardware. I was able to use the trial version of that (from MS-DOS on an old IBM compatible) to recover images of my disks.
I transferred the images to a newer Linux machine, and was able to use dos33fsprogs https://github.com/deater/dos33fsprogs to extract individual files and confirm that the recovery was successful. I also tested some of the disk images in an Apple ][ emulator.
I also have a couple of old TRS-80 disks (possibly a version of CPM?) that I have not been able to recover, although I haven't really tried very hard either.
I agree with plain xterm. Others tend to annoy me.
It's true there are a number of oddities about xterm that might put off people who've never used it before. By default no scrollbar, and once you enable it, it is kind of odd in that you don't use "modern" conventions to interact with it. Its menus and other features are hidden by keystroke combinations that are probably hard to discover if you don't already know about them. I don't like some aspects of the default configuration. I've heard the code is a mess internally, although I haven't checked. Etc.
But I still think xterm is the best. Some emulators flicker when scrolling; not xterm. It just seems faster, and I'm spoiled: even a small fraction of a second response time seems excessive to me. Uses very little RAM. Very configurable if you actually take the time to search through the man page. No superfluous decorations around the terminal (even a scrollbar) unless you want them. Doesn't depend on any huge modern GUI toolkits; if you can run X at all, then you can run xterm. It's available everywhere; get used to it once, and you aren't constantly getting used to other terminal idiosyncracies. Etc.
My personal configuration:
! Very useful to quit out of vi or less, and still refer to
! what you were seeing while typing next command:
! works better with the black background I like above:
What ever you want is going to cost a little more than it is worth. -- The Second Law Of Thermodynamics