I guess a combination is the best compromise: writing a game (or several games at once?) while writing the engine features that you need at the moment.
Guess that is what the article tries to suggest but not places the focus on ...
I agree with you, and always feel like this article is misquoted.
Sure, there is the classic you don't necessarily need an specialized engine speech (what I also vouch for). But the most important paragraphs are the last two, where he says one should "grow an engine" by making several simple games. This allows you to really see what works and what doesn't earlier, and in the end you'll have a better result than an engine built based simply on theory, but with little to no real use until it is in a really advanced stage, where changes are way more problematic...
He preaches against this making an engine as an end thought, in contrast with making an engine as a means to an end.
Of course, I have made games where most of the code was so specific it had little use outside, and would require more changed/new lines than kept ones. If one wants to follow what that article says, he still has to keep in mind all of those engine concepts, and not ignore completely and just make what the specific game requires...
As for me, I can say I searched a 2D engine for my last project, but none fit my requirements.
So I am coding it along with the project, and I am pretty sure that, when I go over to the next one, It'll take 1/2 the time, even less.
So, my friend, if you want to create a 2D engine, go ahead! But make it differently. Create a simple game while keeping your code clean and decoupled. Then pass the reusable parts to another project and, again, keep it clean and decoupled while adding more features. You'll have a nice and cooperative collection of tools in the end.
... or plan and create an engine, based on theory. You can put a simple 2D engine up and running in a few months.
Just remember you can run into one of these:
http://jb.404whylo.com/1279/Reality-101-Failure