I have a slight bone to pick with the author's statement that Unix is homoiconic – sure, I can tail and patch a file, but it doesn't mean that I can seamlessly and quickly manipulate, generate, and execute the canonical representation of executable code in the same way that I can do with s-expressions, quote/quasiquote and eval. I think the bar for meaningful homoiconicity is should at least be raised to include that.
If "I can read my source just into the canonical datatype" was the standard for an environment to be meaningfully homoiconic, you could easily argue that bare metal was homoiconic for the same reason. And in fact I'd argue that it would be easier to hand-assemble VAX instructions to write more opcodes in memory (because the VAX-11 had such an extensive and convenient instruction set, especially all of the three-operand bit swizzling and manipulation instructions) than to do C code generation with a base Unix environment.
I find the word 'homoiconic' very hard to define anyway. For example, I think Tcl is also often described as homoiconic, which manifests in being able to make e.g. custom control structures (https://wiki.tcl-lang.org/page/code+is+data) although something like Haskell also deals with that quite well. However, in say Javascript, you would need to use special syntax when using every {} so that the block content can be seen (e.g. by wrapping it in a function, or passing it as a string to be eval()ed).
In the case of Unix, the question is probably "what is the canonical representation of executable code". I think the author's intent was to mostly talk about shell scripts, and not something like C code. Manipulating shell scripts via e.g. sed is, I think, pretty doable.
I'm also a bit confused why homoiconicity needs to be convenient to be real. Most people don't find shell a very convenient language in other aspects, either.
If "I can read my source just into the canonical datatype" was the standard for an environment to be meaningfully homoiconic, you could easily argue that bare metal was homoiconic for the same reason. And in fact I'd argue that it would be easier to hand-assemble VAX instructions to write more opcodes in memory (because the VAX-11 had such an extensive and convenient instruction set, especially all of the three-operand bit swizzling and manipulation instructions) than to do C code generation with a base Unix environment.