The analogy in the article is inferior.
Here comes the standard HN automobile analogy.
The car makers eternally release little light weight cars that are fattened up with cruft until they're as heavy and expensive and complicated as the dinosaurs they were originally meant to replace. At which time car makers birth a new little stripped down lightweight simple compact car line. That design pattern is self similar and fractal in that even car engines and transmissions and car radios undergo a similar pattern of revolution to make something new, then evolution to slowly and methodically make it the opposite of the original goal, repeat forever. This design pattern also applies to computer architecture.
To fight the problem of hardware evolution making life pretty hard on programmers, source code compatible OS and libraries were invented that could run the same software on vaguely similar hardware, on mainframes in the late 60s at IBM and on PCs in the 70s CPM era, later extended into the "home computer" series era in the 80s, then into the msdos era. This became unwieldy and too complicated for the end users so it was replaced.
The same people implemented the idea of OS packages, again more or less in the 60s on IBM mainframes or the 80s on early unix boxes. The idea is to compile emacs to be integrated very deeply into the OS and cooperate with every other piece of software. This is contemporary. However especially in NON-FOSS it doesn't work and doesn't scale and is very expensive if not impossible to implement, being the only closed thing on an open system is a nightmare for everyone and everything involved. The stereotype in the 90s was only one service installed on one MS windows server, even if that meant it took 20 MS servers to do the job of one unix server. Anyway, expensive, complicated, hard for end users.
Again the same people implemented the idea of OS virtualization. Again, IBM mainframes in the 70s with VM, and early PC hardware experiments with TSRs and multiprocessing in the 80s to give "two computers at once". This is also contemporary, enormously more advanced today, of course. It turns out that running 50 OS kernels on a single piece of hardware is kinda wasteful although possible and cooperation gets complicated and unwieldy so time to replace again.
Again the same people implemented process jails / chroot on the BSDs and eventually after some decades linux finally caught up resulting in docker. So now your packages don't cooperate or interoperate at all with each other or the OS, which solves all the problems where the previous technology didn't work, and creates massive new problems that never existed mostly where the old technologies worked great. There are of course completely separate new problems. It turns out that a system designed to eliminate interoperability between packages interoperability a huge PITA and there are other problems that make use unwieldy and complicated, hard for end users.
Again the same people implemented (this section to be written after 2016). Maybe IOT. Maybe collapse of hardware prices faster than business demand means 20 rasp-pi cluster is cheaper and easier to maintain than a single beefy desktop running 20 virtual images or 20 docker containers. Maybe FPGA on the desktop means people will just synth up whatever matches this hours workload. Maybe cloud will finally work and no one will maintain servers anymore, it'll all be magic, or at least push the magic to someone else who now has the same old problems. Maybe SaaS means we'll all be customers and most productive software will run on internet scale clusters not individual machines, individual machines will be dumb webbrowser terminals. Who knows!