People look at C in isolation but don't realise it was designed to be part of the full Unix system that included Sed, Awk, M4, Lex, Yacc, Sh and all the other tools.
Writing custom C abstractions with Awk is fairly trivial and you end up with efficient C code that can be further processed or tuned. Thats what tools like Awk are there for.
The compiler itself is built on the same principles doing successive transformations on source, IR, assembly etc. There is really no rigid boundary.
If you want C with custom abstractions a custom dialect that compiles to C makes perfect sense. That use case was taken into account in its design.
"Write programs that produce and generate text, because that is a universal interface" is not a good principle for a compiler. (In fact, I think it's not really a good principle all around, and Unix is worse for it, but especially for a compiler.)
The author of the article is not writing a compiler.
I fail to see how that quote has any contextual connection with the current article or compiler design. A discussion about the merits of Unix text streams or text in general is another discussion entirely then the current one.
You yourself said "there is really no rigid boundary" between a compiler and a preprocessor. By most practical definitions of a compiler, the "C amplifier" discussed in the OP is a compiler, and is definitely similar enough to suffer many of the same issues as a compiler. In particular, I think what pcwalton is getting at is that in such a "pre-processor", it's likely that you'll eventually want more expressive data structures than text can comfortable offer you.
Its not a compiler it a pre-processor.
People look at C in isolation but don't realise it was designed to be part of the full Unix system that included Sed, Awk, M4, Lex, Yacc, Sh and all the other tools.
Writing custom C abstractions with Awk is fairly trivial and you end up with efficient C code that can be further processed or tuned. Thats what tools like Awk are there for.
The compiler itself is built on the same principles doing successive transformations on source, IR, assembly etc. There is really no rigid boundary.
If you want C with custom abstractions a custom dialect that compiles to C makes perfect sense. That use case was taken into account in its design.