This is more of a long comment than a real answer.
The behavior is even more confusing that what you describe. I used your file but added a misspelled word in a comment and a "fake" TeX command with a misspelled word as its argument
Behavior that I saw:
aspell -c test.tex this gives an error for "plainnat" and "rwt", but not for "qwrx". I guess my aspell doesn't need the
ispell-buffer in emacs gives an error only for "rwt".
flyspell-buffer in emacs gives an error for "plainnat", "rwt" and "qwrx".
- Putting point on "qwrx" or "plainnat" in emacs, and then using either
flyspell-word gives an error.
- Putting point on either "bibliographystyle" or "bdfg" in emacs, and then using
ispell-word gives an error, but using
flyspell-word gives no error.
- All of the above was verified running
ispell-kill-ispell before running the commands, to ensure that you start with a fresh ispell process. But if you, e.g., spell-check the buffer with
ispell-buffer, "(a)ccept" "rwt" as an OK word for this session, and then run
flyspell-buffer, flyspell will no longer complain about "rwt"
I believe that what's going on is that neither
flyspell send the entire buffer as a unit to aspell and ask it to spellcheck it . Instead, the two modes go through the file one word at a time, and send each individual word to aspell. While
flyspell does eventually call the function
ispell-word to make the actual call to aspell , the logic of which words to spellcheck is different in
ispell. It appears that both contain logic relevant to TeX/LaTeX, but not the same logic.
So aspell never gets a chance to apply its custom rules regarding TeX commands and their arguments, because it doesn't realize that the word "plainnat" is part of a TeX command.
I was using emacs 24.3, AUCTeX (although I don't thnk that AUCTeX does anything that really changes this behavior), aspell 3.1.20. Cygwin.
 This is implicit in Tyler's answer, but I think it's worth pointing it out very explicitly, because emacs' behavior here doesn't make any sense until you understand this!
 This probably explains the behavior in my last bullet point.