...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future.
I can just about see how we can package up all our existing code into docker containers, sprinkle some magic orchestration all over the top, and ship that.
I can also see, as per the article, an argument that we'd be much better off with fat binaries. But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? And if your answer is "rewrite your entire codebase in golang", then you clearly don't understand the question; we don't have the resources to do that, we wouldn't want to spend them on a big bang rewrite even if we did, and in any case, we don't really like golang.
All of which makes this article seem oddly academic to me. There's a lot of value to something that can be layered on top of your existing solution for those of us who aren't starting greenfield projects.
[1]: Also, while "fat binaries" is a great term, it's one that already exists and means something totally different.