The complaint is more about bad interfaces. One of the examples (unix command line tools) has a very clumsy interface if you're trying to use it from within a lower level program: create pipes for input & output, fork, exec, use i/o on the pipes to feed data in and get results out, waitpid, figure out how the tool exited... this is slow, annoying to implement, has many failure modes that would not exist if the interface were a direct function call, and it's inflexible in that you'll be unable to use the core functionality provided by the tool if your data cannot be realized as a simple text stream that still makes sense to the receiving tool. And you can't extend the core functionality e.g. by passing another function to it. That's a huge amount of friction to using code that is already there, because of bad interface. And that's why people reimplement those tools instead of composing programs using those existing tools.

Likewise, FFIs exist, but often it's just easier to reimplement something in your language instead of trying to use the existing implementation from another language.

(Author here)

It's not about interfaces being an impediment but there being too many composition models, none of which seem to scale very well. A composition model is more than an interface. E.g. the way you compose a C program is you write the pieces (functions, structs) that are designed to fit together in certain ways, and then run the compiler which binds these together. The way you compose a web application is you invoke multiple processes that have a pre-shared notion of the protocols and they bind with each other. We're inventing model upon model, stacking them up like an wall of rocks. I'm saying we should look for models that are powerful but compact and can scale up. It should also be something that leads to less reimplementation because composition within it becomes easier. I don't think we have such models and I believe this needs deeper study.