Moving game data into config files has several advantages:

* You can edit these files without having to recompile the game. Which can, depending on your technology stack and the scope of your game, save you a lot of annoying waiting time in your testing loop. With a bit of extra work, you can even make data files hot-reloadable, so you can experiment with them without even having to restart the game.
* You can edit these files without having to know the programming language and the development tools. This can be extremely useful if you aren't working alone but collaborating with people who are not programmers.
* You are not bound to the syntax of your programming language. Not every programming language is equally good at encoding data literals in the shape you need and in a way that is easily readable and editable. So moving that data to a configuration file can make your life a lot easier.
* You have *the option* to create editing tools that allow you to create content a lot faster (whether or not you should is a question of how much time it would take vs. how much time it would save. These are highly dependent on the project).

However, I agree with the TDWTF article on "Soft-Coding" logic to a level where the configuration language basically becomes so convoluted that all the above advantages are lost. When everything is soft-coded, then nothing is soft-coded. It's hard-coded in a proprietary programming language that is often worse than the language that was used to build it. 

My general rule of thumb: **Logic belongs into code. Data belongs into files.**

But very complex games made by large teams often do move some logic to script files. That way they create a layer between the "arcane", highly technical code of the core game and the "dumb" configuration files that are just data. A scripting language you can teach to level- and game designers that allows them to do trivial logic without asking a programmer for help, but which isn't powerful enough to seriously break things. A common example are dialog trees in RPGs. If a writer wants the NPC to say one thing if the player made decision A and another thing if the player made decision B, then they shouldn't have to bother a programmer with that. Especially when there are about a hundred situations like that in the game.

Where to draw that line between what to program and what to script is a judgment call. There is really no hard rule to follow here, except the obvious one: Do what you think is less work.

To take the example of the one-off spring catapult thing from the question: I would turn this thing into an entity that can be placed in the level files. Even when it's just supposed to exist once in the game. That way the level designers can easily experiment with where to place it exactly. It also makes sure that when you look at the level file, you get the full picture of what is and isn't in that level. You can see that this empty plateau in the middle of the level isn't just wasted space, because that catapult is there. However, the actual logic behind it, might work better if it is hard-coded in a class.