Very nice article. Sound advice (and argumentation) and well written (my latent grammar guardian did not wake up ;).

I would like to add / expand a bit on the 'abstraction' point (which seems to draw most of the refutations). In my mind there are (at least) 2 sides to this.

One aspect / use of abstraction is in the 'understanding and solving the problem' part.

To me this is about dissecting and abstracting the problem into solution building blocks, recognizing which algorithms / data structures / patterns are or could be appropriate for the problem at hand.

In this context I would argue it is valuable to learn what 'building blocks' are out there, how they can be used and when they are useful. To be clear: I fully agree that this does not mean you need to know by heart HOW to implement all these building blocks (in all possible languages).

The second aspect of abstraction is (in my mind) about optimizing for maintainability (and related aspects). So I approach it in a similar fashion as what you suggest on 'optimization', it is mainly something for a second pass (unless you like to get stuck in an endless refactoring loop' of course ;)