The first half boils down to (a) research existing solutions, (b) avoid NIH when you can and (c) refactor your code as you find commonalities and points of re-use. The second part is mostly about designing a system that could be used/extended by someone else (separate the generic from the the specific, treat it as open source).
Those are very valid points. Thing is, in following those very valid points one could probably write another article with a far greater number of examples (and a far better lesson) where the best course of action is to NOT roll your own framework and prefer to adopt some existing code and make the necessary extensions/modifications.
To illustrate, I checked the morepath "framework". It seems to tick all of the boxes one would expect from a proper open source "framework". It even has more documentation than I would expect from such a small open source project. The one point where it fails is that it never gets to give one simple example of a pain point that this project solves that all of the other million web frameworks don't.
In the end, it seems that the author is looking for an ex post facto rationalization for some of his projects that had a lot of his time invested but no external interest afterwards. Too bad that it seems that he also took the wrong lesson out of it.