Anyone who's had to analyze complex systems at a high level will recognize that this is a pattern that often emerges in some form. The over all pattern happens in game engines, plugin systems, UI frameworks, in service buses, all over the place. It's just now at the code level. It's a good observation, though it seems the author has arrived at the correct conclusion/analysis and tried to shoe horn it in to fundamentally lacking systems (i.e., other languages/stacks that are inherently not functional, have side effects, and do not work off "events"/sync points).

My thoughts on this are: append only programming is less effectual than having an over all append only system, where many programs take input (including the original source "message"), then hand off the out put to the next program in line. Which programs get run depends entirely on that run context's configuration. When you have disparate programs working towards a final goal, and these programs are defined in a readable configuration it gives you quite a few benefits. Good clean logging structures, easy to reason about, easy to change (feature toggling, data migration points, etc), and easy to clean up when required.

I call it unix'ing your systems.

There's a lot of comments calling this silly but please attempt to give it a few read overs and apply it to systems you've worked with. Hopefully they've been large enough to draw similarities to what he's talking about in a very clean, academic manner.