You can start by having no data files. And by pursuing a single source of truth, your code might evolve to have sections where it calls a method multiple times in a row with different data for initialization. Which then can turn into some large data structure literal with all the data over which you loop over. And then it grows large enough - or changes often enough - that it makes sense to move it to its own file... And you might want to:
- Make sure it only has data.
- Allow non-programmers to tweak it.
- Use some other software to make it easier to work with it.
It is ultimately a judgement call to make it a JSON file or a CSV file or something else. There isn't a hard line because it is about making the workflow easier...
When you have few game components, and they are all significantly different from each other, and you do not need non-programmers to be able to tweak them, then you will find that using data files is more work than it is worth.
Conversely, if you have many game components, that differ only - or mostly - on data instead of mechanically, and you want to make it easier to edit them (either for development, or to make it easier to automatically test variations, or for designers to easily tweak the values), then data files are probably worth it.
For example, in some video game there could easily be hundreds - or thousands - of items. And this can make them hard to maintain if they are hardcoded.
And there could have - again, for example - 10 weapons, which differ only in how much damage they do, how much they cost in NPC shops, what sprite art they use, and stuff like that.
And you want designers to be able to quickly tweak these values for rapid prototyping.
Thus, you might use a CSV or JSON file instead.
Or, perhaps, you do not need to have designers tweak the values, but it might be convenient to use spreadsheet software to look at the values at a glance to have an idea of their progression, which might make a balance review easier. Plus, spreadsheet software will also make it easier to make data visualizations from the data.
And - similarly - spreadsheet software might allow you to use formulas to define these values quickly.
Or, simply, it is a matter of making it easier for you to add them to the game because a table is what the designers give you already. Or you might convince them to give spreadsheets to you. Tell them which is the table format, perhaps some example data, and they might express part of their future updates using them.
When you go over your list of components you are likely to find that they do not differ only on data. Which is arguably good, because this means you have differences of kind, not just of differences of degree.
Yet, you can create classes/systems for their behaviour. And then in your data file you specify which they use. For example a bow that inflicts poison damage would use the ranged weapon behaviour and the inflicts poison behavior, while differing from a crossbow that inflicts poison in data only.
Thus, these behaviours would be code.
Another reason to keep something in code is to have a guarantee that it is present. Usually you would design such that none of the components depend directly on another...
This goes both ways:
Depending on data allows you to decouple some components of your game.
For example, fire damage destroys wooden weapons, and corrosive damage destroys metal weapons. Then each weapon can specify their material. But at no point the code for fire damage has hardcoded the list of wooden weapons, and so on. In fact, there might be none in the game and the code still works.
If a component is required to exist for some mechanics to work, it is better to keep it in code.
For example, the aforementioned fire damage does not depend on any specific weapon, but it depends on some weapon type, having some material, and some way to destroy them. Thus, those are things you need to keep in code.
Now, let us say you have some vampiric powers in the game, which will steal hitpoints. Your data files can specify which attack has this effect, but for this effect to exist, hitpoints must exist.
Even if you generalize hitpoints, stamina and mana into a single concept, and let the power specify which one they work with. It does not mean that you will define hitpoints, stamina and mana from a data file (they are only three, they are mechanically different, and designers don't mess with them often).
However, there might come a time in the future when a data file becomes convenient (Perhaps in some future version there will be ten instead of three, they are more mechanically similar, and the designers are messing with them more often, so you decide to put them in a data file that they can tweak and test what happens instead of programming every change).
Thus, I want to reiterate that it is a judgement call.
Keep present requirements are paramount, so keep them the priority. And pay attention to the steps of your workflow that require most time and effort. Think how to aliviate them. And you might find that at some point data files would be a good option. Or something else entirely.