Performance, ease of use, preventing you from doing things wrong, etc. are all pretty valid reasons for using a DBMS, but there's a more fundamental reason you'd use one in the first place.
When you're trying to solve a problem, you should first try and specify what the domain of the problem is. In this case, it's quite obvious: our problem is that we want to implement a game server to emulate the functionality of official conquer servers so we can use the existing client more freely.
More specifically, the main problem is that of implementing the logic of a virtual world, specifying how virtual entities interact with eachother, blah, blah. In this problem domain, there is no mention of storage, because it isn't part of the problem. Storage is only one particular means of implementing the solution to the problem. We really need to consider storage to be it's own domain, separate from the domain of the game logic.
In a similar sense, we know that we need to communicate with the game client over TCP, using a protocol the client understands. This is part of our overall problem of making the game server, but it isn't really part of the primary problem domain: the game logic. In fact, the game logic doesn't need to know anything about the communication being used, in the same way it doesn't need to know about the storage being used. So likewise, communications should be in their own domain.
You might isolate some other problem areas into their own domains too. In the end, your overall problem domain has become more managable by breaking it up into sections that you can work with in isolation. The main problem domain of implementing game logic doesn't need to have the confusion of storage and communications associated with it. If we use a diagram to visualize this, it'll look a little like this, where the size of each of the subdomains are relative to the problem size (and how much code we should be writing for them.)
This looks nice, but if we move onto the storage now, we can begin to consider how things will be stored. This could be quite simple if we just vomit our data onto the hard drive without any consideration as to whether the data we are writing is sensible, but the chances are that will come back to bite you later. In order to make sure that we are writing sensible data, we need to write sensible code to store it.
When it comes to writing that sensible code though, you soon find out that it is not simple, except for the most basic of data being stored. Whenever you are storing non-trivial data, there's a lot of boilerplate code you need to place to ensure you're doing things properly, efficiently and in a modular way, so we can make the most of the code. If we do this, and do it right, our overall problem now looks a bit like this:
The problem is quite clear isn't it? Our problem of "emulating a game server" has now become a problem of data storage. Our solution has been overtaken by something that wasn't even part of the original problem, and we are going to waste a lot of resources doing it this way.
So the reason we use a DBMS is so that we can focus on the domain of our problem, and not one of storage. The DBMS themselves are projects which focus on the domain of storage, and they do it very well - in an abstract way that is easily reusable from other applications. These DBMS systems have millions of lines of code to make sure they're doing things right, and doing them well - you could never hope to match them in a specific implementation of any non-trivial data.
