I agree with most that you have written there, and I already said that Schneier"s book is not useful for someone who wants a recipe for implementing a cryptographic system in practice.
As you have said, all the descriptions of obsolete ciphers are useless for someone who wants a practical implementation, for which AES is the right choice.
However, in this thread the discussion was about a book to introduce someone in the domain of cryptography, not to make him a professional who will immediately design a cryptographic product. For this initial learning purpose, all the descriptions of historical ciphers are useful.
No really competent cryptographer can understand what is good and what is bad in a block cipher like AES, without studying all the previous block cipher designs, especially which were their flaws, starting with IBM's Lucifer and DES, until all the candidates of the AES competition.
The best way to study cryptography is not from any books but from all the relevant patents and research papers, but to reach that level it is good to be exposed in the beginning to more accessible books, like the Schneier book, even if those may contain some things that later will require corrections.
Not even among the newer and better books have I seen anyone that does not contain a few confusions or mistakes.
While most of your objections written at that link are correct, I can find various things to nit pick.
For instance you write "We know today that you want to encrypt, then authenticate; to do otherwise is to invoke Moxie Marlinspike’s Cryptographic Doom Principle".
You make here reference to an excellent research paper, which has a well-deserved reputation, but in reality the conclusion of that paper contains additional information that you do not mention, and which invalidates your addition about the "Doom Principle".
What that paper proved is that "Encrypt-then-MAC" is what you must do when "Encrypt" and "MAC" are black-box algorithms, about which nothing is known.
On the other hand, for particular "Encrypt" and "MAC" algorithms, it is frequent that "MAC" then "Encrypt" is perfectly secure, and this was also explained in that research paper.
The reason why you may want to do "MAC-then-Encrypt" for certain specific algorithms is that in those cases it is possible to obtain a higher performance than when combining generic algorithms into "Encrypt-then-MAC". The reason why "MAC-then-Encrypt" can be faster is because in this sequence the MAC algorithm may be a weaker algorithm, and weaker algorithms can be faster.
Some of the most important AEAD algorithms (Authenticated Encryption with Associated Data) are actually built as "MAC-then-Encrypt" algorithms. They are specified as single algorithms precisely to prevent the user from combining in another way their "MAC" and "Encrypt" components, which unlike the carefully designed combination from the AEAD specification, could be insecure.
The correct recommendation about "Encrypt-then-MAC" is that, when in doubt, you should do "Encrypt-then-MAC", but when you are a cryptography expert and you know what you are doing, you should do "MAC-then-Encrypt" with correctly chosen, compatible algorithms, for maximum performance.
The "Encrypt-then-MAC" recommendation is of the same kind like the recommendation that you should use a standard validated cryptography library and you should not write your own. This is good advice for most people, but obviously it cannot be the correct advice for everybody, otherwise no standard validated cryptography libraries would exist.
In another place you criticize Schneier because he recommends to compress a file before encryption because "It turns out, no. The length of the messages in a cryptosystem is also a potential side channel".
What you say there is not a counter-argument to Schneier. First, in the case of a file, which presumably would be encrypted only once, it is very unlikely that an attacker could mount the chosen-plaintext attack that you described for compressed messages.
Even in the case when encryption is applied to communication, not to stored files, there are trivial counter-measures for hiding the length of the transmitted data, regardless if it is first compressed, or not. One can transmit only packets of the same length. If too much time passes without accumulating enough data for transmitting a whole packet, the remainder of the packet can be filled with random junk, and it can be transmitted.
So the recommendation of Schneier is valid. Frequently it is desirable to compress data before encryption. What you say about the need to avoid leaking information from data length is also correct and important, but it is a separate problem.