If you have to parse some HTML that you get over an HTTP connection - you're writing a crawler, say, or you want to extract RDFa metadata, you have to deal with the following, surprisingly common case: both the header and the html document contain encoding information, and they disagree. The RFC states that you should trust the header, but in practice, that's certainly not always the case - nor even, in my experience, is it the case the majority of the time.
If you decide to use the meta tag, that means that you have already strarted decoding your byte stream, get the encoding, then need to re-interpret the bytes you've already read. I have seen a lot of pages that declared their encoding after the title tag.
What's worse, you can't know whether you have a meta tag until you've parsed the whole head, which can be huge with hundreds of kilobytes of inlined javascript and css.
The argument that you should just read the first 1024 bytes and assume utf-8 if nothing is found is just not satisfactory - I want the encoding of the documents I'm parsing to be correct all the time, not when the remote host follows the rules. If I'm writing a crawler, the remote host cares nothing about my needs and I'm the one suffering from my unwilingness to be flexible.
So, yeah. Don't use the meta encoding tag, and trust your user agent to save the html code in a sane (utf-8) encoding. There is no reason to store encoding information in an html file, just like I doubt your source code always starts with a preprocessor instruction declaring the encoding that the compiler should use.