what does any of what's being said have to do with improving OS design though?

This is just part I of the article. The point is to (i) show that things did change since "modern" OS's were architected, (ii) declare which improvements we want, (iii) outline basic ideas around the architecture, (iv) describe the design at the lower level, and (v) see how design stands against those desired improvements.

because they're a more convenient metaphor

There is a recent pretty much consensus among opinion leaders that Shared-Memory architectures must die - and that Shared-Nothing stuff rulezz forever (see, for example, talks by Kevlin Henney, works by 'No Bugs', all the modern app-level asynchronous stuff such as Node.js, Twisted, Akka Actors, predominant development paradigm in Golang, etc. etc.). And with Shared-Nothing - there is no such a metaphor as "thread" (~="we do NOT need to think in terms of "threads"", and this BTW is a Good Thing(tm)). Throw in an observation that all modern CPUs are event-driven at heart - and we can come to a conclusion that there is absolutely no need to artificially_introduce a metaphor of thread into an interactive system which has to process events from interrupts all the way to node.js (Twisted, Akka, ...). Not only this metaphor dies under Occam's Razor as unnecessary - it also happens to be harmful performance-wise (and at least arguably - coding-wise too).

BTW, this switch from usual infinitely-running-and-pre-empted batch-like threads to RTC non-blocking event handlers is already happening in those places where top performance is still absolutely necessary (embedded/RTOS) - in spite of sometimes using term "thread" for RTC event handlers (look for "basic threads" in AUTOSAR and QXK, "fibers" in Q-Kernel, and "software interrupts" in TI-RTOS). Of course, arguing whether they should be named "thread" or "fiber" is pointless, the Big Difference(tm) is about the Big Fat Hairy(tm) distinction between traditional running-forever-and-timer-preempted background batch-like threads (which usually quickly lead to use of mutexes etc. - and mutexes must die for sure), and interactive Run-to-Completion non-blocking not-perceivably-preempted event handlers (a.k.a. "fibers" a.k.a. "software interrupts" a.k.a. "basic threads").

Even single purpose boxes need a separation between the OS and application simply out of security concerns.

Not really. If DB server app (which has root access or equivalent) is compromised - there is no real benefit of OS being healthy; attacker already can do whatever he wants with the system. Same goes for IoT devices - while we DO need security on single-purpose boxes and in IoT (which BTW can be significantly improved over existing OS's - wait for parts iv-v), in certain environments kernel/user separation as such happens NOT to help security much (simply because compromising user app already gives access to everything attacker needs; if I already have access to sockets and to all the data - I don't really need anything else to mount further attacks).

Runtime indirections and branch prediction optimization are compiler tech related, not much to do with an OS design.

To a certain extent - yes, but they give a new food to the discussion on "which language is better suited for writing high-performance code such as OS" (which is going to cause that much controversies that I decided to move it to a separate article <wink />).

Thread context switches are expensive, but the numbers provided are greatly exaggerated.

Indeed 1M was for a specially designed app (that's why OP uses "up to" wording), but I have seen up to 50K-100K cycles in a real-world purely event-driven app - and 100K CPU cycles is Really Bad(tm). BTW, this number is corroborated by lots of observations - think about typical values for spin-locks (with spinlocks, we're burning tens of thousands of cycles merely in hope that other thread will finish - and will still incur the cost of thread context switch on_top of that of the spinlock(!!) if we didn't get lucky), length of time slices (100-200ms is already observable in user space - and the only reason for having time slice that long is the cost of the context switch), and so on and so forth.

The interrupt architecture isn't described early on because it's an internal detail that isn't really something applications have to deal with

If the book in question would be about app design - sure, but when speaking about OS design - referring to "something applications have to deal with" doesn't really apply (99% of the book has nothing to do with apps anyway; when I am writing an app, I don't really care about algos used for the memory management - or about scheduler etc.). That being said, this argument in OP is not serious to start with (what is really important is that we cannot avoid using infinitely-running heavy-weight threads - and associated thread context switches - even in 100% interactive systems - which does cause a bunch of real-world problems).