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.
(At this point I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options.)
That doom principle is: "When you receive a message, the very first thing you can do is verify the MAC".
What confused me was the name of Moxie Marlinspike, because this principle was not coined by him (in 2011), but it was discussed at length during the nineties of the last century, by the designers of IPsec, a decade and a half before Moxie.
This principle was the reason why IPsec chose to do "Encrypt-then-MAC", unlike SSL or SSH. The differences between IPsec, SSL and SSH in the order of encryption and MAC computation prompted Hugo Krawczyk to write in 2001 his paper "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", which clarified the properties of the 3 different orders used at that time by IPsec, SSL and SSH.
Nonetheless, this "Doom Principle" is obsolete.
30 years ago, when IPsec was designed, it was true that doing first only the MAC computation saved time for the case when decryption was no longer required (because the packet was corrupted or forged).
Nowadays, reading the encrypted data from the memory is normally the bottleneck, not the MAC or decryption computations. Therefore, one should never do 2 passes over data, one for MAC and one for decryption, but one should do a single pass, during which both MAC and decryption should be computed, regardless which is their order. Even when small packets are decrypted, so the second pass would find the data in the cache memory, doing a single pass over the data is still faster.
When a single pass over data is done, it no longer matters in which order MAC and encryption had been done, regardless whether the data passes or fails the integrity verification.
> I'd be puzzled by anyone doing generic composition of ciphers and MACs, given the available options
I agree. Today, most people should use only one of the standardized authenticated encryption algorithms, like those specified by TLS 1.3 or SSH.
On most modern CPUs (which have dedicated hardware for both AES and the GCM MAC), doing something better than this cannot be achieved by any generic composition of ciphers and MACs, but it can be achieved with other authenticated encryption algorithms, which have not become widespread mostly because of the broken US IP laws (i.e. they were covered by various bogus patents).
I was writing about EtM constructions before Moxie wrote that post (you can see me preening about Bellare and Namprempre in Twitter search), but Moxie's post is the one everyone remembers, so that's the reference. What's "obsolete" about the advice now is that nobody builds cryptosystems by manually gluing a block cipher mode to a MAC anymore. But in the 5 years prior to that post, violations of the "principle" were the most reliable way to break cryptosystems.
Nobody's arguing that cryptographers can't design hermetically sealed authenticated encryption modes that play with the ordering of encryption and authentication. That wasn't what Moxie was implying either.
I think that you might confuse IPsec with SSH in this statement.
IPsec chose since the beginning "Encrypt-then-MAC", which is proven to be secure with any good encryption and MAC algorithms.
In the beginning, SSL used "MAC-then-Encrypt". This is proven to be secure only with certain combinations of MAC and encryption algorithms. Nonetheless this was not a problem for SSL, because the combinations that they used were by chance among those correct.
SSH used in the beginning "Encrypt-and-MAC", which is the worst choice, and in certain SSH variants it was actually vulnerable.
So I think that you remember some story about SSH, because IPsec got it right since the beginning.
In general IPsec has never had any problem in its purely cryptographic design choices, but its initial variants had ridiculously complex management methods, which could result in security problems due to key or access rights mishandling.
Later, IPsec was simplified, but it had already acquired a bad reputation as being extremely hard to use correctly, which allowed other VPN solutions to become much more popular, like OpenVPN, which were much easier to configure and use.