Yes. You should implement a system to load content outside your main engine.
Headers for succinct answers.
No. It does not consume too much time.
I think the question of whether it is a valid allocation of your limited time is moot; even if only for the fact that it will be a small portion of total project time.
You will spend hundreds (thousands) of hours on a game project that you take to completion. Perhaps not on an Pong clone, but surely so for your complex space game. Compare that to a config file reader. Implementing a system to pipe XML into your main constructor, and subsequently restart to game process, will take maybe 10 or 20 hours. Even if it takes you 50 or 100, it will be a tiny fraction of total project time.
It will save time
It's not a time expense; it's a time investment. And it will pay off.
Workflow matters, and having a config loader will make your workflow better. By creating a system that allows you edit configurations on the fly, you will save countless rebuilds. You can look at the game while it's running, tweak XML, and recheck in seconds. Or you can look at code, find a line of code (among thousands), edit its values extremely carefully (you're in your main engine, afterall), rebuild, execute, get the game back to the testing state, try hard to remember what it looked like before the change, and see if your change had the effect that you intended. Assuming nothing breaks in your engine, your train of though is surely disrupted.
From a more fundamental comp-sci perspective, try to remember that the most time-consuming part of writing software is not having a few extra keystrokes or whitespace. It's bug-hunting. And if you spend a little extra time to make things clearer by writing more verbose code, you save yourself much more time later. In your case, writing a content importer results in cleaner code that will be easier to read. Instead of miles and miles of hardcoded values, your source will feature a simple file load. Likewise, you can read the config file without wading through game engine code. Both parts become more maintainable and easier to debug.
One-member teams benefit the most
If you hired an artist to generate some of that content, you would need to make tools for them to work with. They need to make pixel edits, and see the effects rapidly. You would not dare force them to rebuild code in order to see every change. Their time is expensive, and you don't want to waste it.
Now imagine that artist is very unskilled and slow (programmer artist), and has lots of other stuff to worry about because they are also the main programmer and musician. You definitely don't want to waste that time, or the project will never finish. And, that crappy artist will hate training to be a better artist, because they spend all their time renaming asset strings in code.
Don't do that to yourself. Make the tools, and you will have more time to make a game.