The short answer: the complexity of a 2D engine depends largely on how you choose to implement the renderer and what sort of features you decide to support. You can look at it in terms of technical complexity and architectural complexity.

Go back to the 90s and the renderers were called 'blitters' and often involved handcrafted assembly and algorithmic tricks that caused faster code to be generated (all of which are largely irrelevant now with the modern optimizing compilers we can work with). Today, you can choose between a variety of graphics APIs, both hardware accelerated and pure software, to use as the backend of a sprite renderer. Using deprecated, immediate mode OpenGL or older versions of Direct3D (or even DirectDraw) might be less complex than other approaches, whereas using a shader-based approach can introduce a range of complexity. This is the sort of thing that significantly contributes to the technical complexity.

Then there's features. Each feature you support will introduce a certain amount of technical complexity in the implementation details, but also architectural complexity in how they interact with each other. The more features you add, the easier it is to find yourself with a dysfunctional API without a good sense of planning ahead.

Consider a minimal functioning 2D engine: basic sprites (with no transparency or animation), basic audio (sound effects). You can make a number of games with that alone and is about as small of a complexity as you can have. Start adding in more features like transparent sprites, animation, basic collision, streaming audio, networking and you greatly increase the range of games you make, but you're also driving up complexity both technically and architecturally. Add more features like particles, lighting, rigid body physics, support for thousands of players, and other advanced concepts and you continue to increase the complexity.

I think making a 2D engine is a great learning exercise, especially if you take this approach of increasing the complexity. 15 years ago it was much like a right of passage for aspiring game developers, but there wasn't a whole lot of room for features -- most 2D engines back then were all fairly similar in terms of the feature set. There's a much broader range of possibilities these days, so start out with something like the minimal engine I mentioned above, perhaps using shader-based OpenGL or D3D for the renderer backend. Use that to make some simple games, like Pong, Breakout, and Tetris. Then look at adding additional features and consider how you need to expand or modify your architecture to support them. Then make more games using the new feature(s). Then go back and do it again (another new feature and a couple of new games using it). This will give you some valuable experience. Then later on, if it's something you're interested in, you can take that experience and apply it to developing a simple 3D engine, or in using an existing, fully-featured engine to make a more complex sort of game.

I really don't suggest making a 2D game engine.

You will naturally accrue an "engine" of sorts after making a variety of games.

Unless, of course, you've already programmed games and are doing this to learn OpenGL. In that case:

Try looking through some other libraries (SFML, SDL, etc.) and see how they handle creating games. Don't copy them, but understand what someone using an engine wants. (This should be easy if you've already used a 2D Library). Then, try to implement these features. Be warned, making a 2D Engine takes a long time, and with the plethora of libraries available today, it's kind of pointless.

I am torn regarding the article.

When you write a game instead of writing a framework and using it for a game, that often leads to problems with the cross-cutting concerns.

You end up with tangling and scattering, you do not go for separation of concerns. The "writing an engine" approach leads to better auto-pilot decisions.

On the other hand I love the TDD approach. In theory you can write a game and keep the functionality you are adding clean ... and the architecture flexible.

The problem is that there are many ifs for that to go well ... most people do not think about adding functionality the right way until they have played the thought of what adding a feature as engine functionality would look like.

So I like the engine approach and think about that as best-practice-training-wheels.

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 really don't suggest making a 2D game engine.

You will naturally accrue an "engine" of sorts after making a variety of games.
Unless, of course, you've already programmed games and are doing this to learn OpenGL. In that case:

An article written 7 years ago, seriously? When you were posting, did you get confused between a 3d and 2d engine? If you were talking about a 3d engine then i would disagree less (disagree) but 2d engine, then i disagree as i've seen 1 year for that "long time".
How does one accrue any reasonable engine between a racing, puzzle and rpg game? If you said writing a game without a game without an engine but with libraries, then i get it considering you have to make the parts work together which will lead to an engine.
@stealthpandemic: make the engine if that's what you want and Aldacron gave really good tips.

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

So, my friend, if you want to create a 2d engine, go ahead! But make it differently.