a) "Write small programs that do one thing well."

You could argue that programs like editors or compilers violate this principle; they're certainly not small and simple. But I can't imagine a compiler which is made out of small tool-like programs; and editors like that are very annoying. Mostly, a compiler does do one focused thing, and a modern compiler typically does it well, even though it's not a small program.

A good example of a program which violates this principle is a typical modern web browser. Not content to retrieve and format web pages, a typical modern web browser contains multiple embedded programming languages, and all sorts of fancy stuff. The result is that web browsers are known for being some of the buggiest software we use, and this bugginess is particularly important because they are on a security boundary (you visit untrusted web pages and they mustn't be able to execute arbitrary code on your computer), so we have constant urgent security updates.

b) "Expect the output of every program to become the input to another, as yet unknown, program." (For example, don't clutter output with extraneous information such as headers.)

I was expecting most students to use "ps" as an example of a program which outputs headers.

The "ls -l" output could have been made easier to parse.

"ls -l" and "ls -R" have extra header-like information which would make for a good answer here.

Most obvious "violates" examples here are about including headers. A good example which is not about headers is "diff". The output of diff is harder to parse than it has to be.

c) "Make programs' input formats easy to generate or type." (Example: Avoid stringently columnar or binary input formats. Another example: Supply good defaults: It should be common to say simply "command" with no command-line arguments.)

An excellent "violates" example of this is "make"'s Makefile file format. Yucky stuff with tabs which is pointlessly tricky.