This stuff is good to know -- I have found the "sed -e" trick and doing pattern matching inside awk help cut down on typing quite a bit. They may even make the script more readable, once you become familiar with these idioms.
On the other hand, I don't know if these type of performance optimizations will have many real-world applications. For example, if you are calling grep and awk inside a loop, and find it unacceptable slow, I don't think you are going to see a big performance gain by calling only awk. At that point, your best bet may be to write that part of your script in Perl (or C, like I did once back in the times before Perl was mainstream).
Is it just me or do most of these seem like premature optimization? I would rather use one command for filtering lines (grep) and another for filtering columns (awk) than try to do both at once.
I generally take the definition of "premature optimization" to be "going out of your way to improve performance". If you know a faster (better?) way, use it. Sometimes, people seem to confuse YAGNI and premature optimization with just "knowing better".
For your grep example, unless you are using the output of grep for something else, there's no reason not to use the awk version except ignorance (which I'm plenty guilty of re: awk and sed...)
It depends on how often you need to write scripts of this sort. If you only write them once in a while, you're probably fine with using two commands, but if you write scripts all the time, it's worth it to know how to do them succinctly.
On the other hand, I don't know if these type of performance optimizations will have many real-world applications. For example, if you are calling grep and awk inside a loop, and find it unacceptable slow, I don't think you are going to see a big performance gain by calling only awk. At that point, your best bet may be to write that part of your script in Perl (or C, like I did once back in the times before Perl was mainstream).