And if you're champing at the bit to tell me that Id writes game engines and is more successful than I am, be aware of one thing. I know Id. I've met Id. I live in the same town as Id. You, sir, are no Id.
That being said, here's Reason Number One To Avoid Writing A Game Engine.
Maturity of tools. The whole "developing tools to make tools" mentality is terrific if your industry or platform is in its infancy. Problem is, it's not. You're developing for a very mature platform using even more mature tools. You're developing at the end of the chain of toolmaking, not the middle. You've got the tools at your disposal to make the end-result of efforts, which is an application for end-users (i.e. a game), not more tools for yourself.
As an analogy, let's imagine for a moment that you're repairing the roof of your house. Now the general game-engine-builder mentality would necessitate that one look at the task at hand, figure out the tools necessary to solve the problem and construct the tools without regard to tools available, no matter their level of maturity, because existing tools will be assumed to be inadequate from the onset and should only be used to construct further tools.
In this instance, you notice that nails must be hammered into your the shingles six inches apart, so you decide that a tool that could better perform the job than the one at hand (namely a hammer) would be a two-headed hammer with heads six inches apart. You immediately set about to constructing this two-headed hammer.
Problem is, unless you intend to hammer in an amount of nails with the two-headed hammer that will justify not only the time taken to hammer the nails but also the time and effort required to construct the hammer, you're wasting your time. More likely than not, you could hammer in all the nails "the old fashioned way" and complete the entire roof-job in the same or less time than it would have taken to construct the two-headed hammer.
Furthermore, you're taking an enormous risk in developing the two-headed hammer, because there's a reasonable chance that, upon completing it, you discover that two-headed hammers don't exist because they don't work as you thought they would, and existing hammers made by tool builders with far more experience than you are good enough to do the job.
That's why people who build end-user products don't waste lots of time at the onset building specialized tools. If you see people building a house, they use tools at hand, even though they're not always 100% suited to the task at hand. If a homebuilder does make a tool for a job (like a cardboard template for some scrolling window-work, for example), it's done very quickly and simply and is intended to be discarded after its use.
Even worse, most of the people I've seen who are developing game engines are developing 'em without even having a well-defined end use for it. That's like making a two-headed hammer just because you're assuming that two-headed hammers are better, and not because you think your roof repair job necessitates it.
Bottom line is that you've got time-tested tools at your disposal, from computers to operating systems to graphics subsystems to 3D hardware to graphics libraries to compilers to level-building tools. You can pretend that STL is a poor tool and you can make a better one that'll be better suited to your games, but you're wrong.
In other words, If you're planning to write a game engine or are in the process of writing a game engine, stop now.
And since I'm feeling charitable, here's Reason Number Two To Avoid Writing A Game Engine.
Reusability is a myth. If you make a game-engine, you will use it to develop one game at most. Pretend that you'll use your magnum opus engine to develop a whole series of robust games, but you won't. The one thing you'll learn in the development of your engine is that your engine is inadequate and must be rewritten.
And this fact will remain no matter how many times your engine is written. If you do end up writing a game with your newly-completed engine, all you'll think is how your project would be more satisfying if you just added one more feature or structured things just a bit differently. If you do manage to complete your game, your next project will inevitably be an improved engine, thus giving your engine a duty-cycle of one game, which negates the entire point of having a reusable engine.
More likely than that, though, you'll grow frustrated with engine-design decisions that you made early on. They'll gnaw at you. You'll feel assured that the project will go smoother with an improved engine. And you'll abandon the work you've done to improve your engine. And that's even worse than the previous scenario. At least in the previous scenario you developed one game, albeit in an unsatisfying way. In this scenario, you developed an engine for which there exists zero games.
So the end result is that you'll have one unsatisfying game or zero games. And that's a lousy choice to make.
If you want an engine that can be used to make reusable games, get one. There are lots of 'em out there nowadays. A good number of 'em were written by people more talented than you and are being used to make games better than yours.
In other words, If you're planning to write a game engine or are in the process of writing a game engine, stop now.
More importantly, these have been proven to work and/or be 'geeral purpose'. Quite simply, if they weren't - people wouldn't be using them.