Data vs behavior
Example: Sins of a Solar Empire defines most of its ships and abilities in terms of JSON files. These JSON files will define, say, the list of individual weapon mounts equipped on a ship class
Obviously, going with this dynamic, data-driven approach is much slower than having native code directly describe the behavior of the system.
You're comparing apples to oranges. Or, more on topic, data to behavior.
Data is fantastic at changing over time. You can add things and change them long after the application was released. Behavior, however, is encoded statically in the application. Changing it requires a new release of the software.
When non-trivial, data is difficult to handle. This is because the developer cannot rely on the existence of specific data values, since data is inherently treated as an unknown value that will only be known during runtime, not development time.
Using your example of Sins of a Solar Empire, you will not find any logic in the game that relies on a ship having a specific amount of weapon mounts. It's likely only going to know what a weapon mount is, and that a ship has an unspecified variable amount of them.
Making your behavior data-driven
Given sufficient effort, you are able to turn anything that's currently static behavior into a data-driven format. However, this requires an additional layer of abstraction, as you're turning your concrete implementation into a configurable object with unknown values that you can't rely on during development time.
This kind of abstraction makes your application changeable post-release, but it comes at the cost of significant additional complexity. At some point, you have to balance how much complexity is too much, and whether the extra effort tax that this brings with it is worth the benefit that it renders to you. It also comes with some kind of risk assessment - do you want to pre-emptively make everything configurable, which takes a lot of effort, or do you want to be clever about which things you make configurable, effectively guessing and risking that you might not make something configurable that you will come to regret going forward?
There is no straightforward answer here. What you're asking to do is almost the very essence of what advanced/senior software developers engage in, in terms of technical analysis and software design.
This is highly contextual, on a case by case basis. It depends on your available resources for developer effort, the impact of features being unavailable because they were not pre-emptively developed, and your ability to accurately gauge in advance whether a feature is going to be needed or not.
Games that are open to modding tend to have invested extra time and effort in doing so, because they are banking on the moddability of their game benefiting them in the long run, either via increased long term player engagement or the devs' own ability to more easily test and patch the game. That investment is a gambit, and one that you need to assess for yourself.
Not to give this a negative tone, but games that release very similar new versions every year (typical examples include sports games and online shooters) tend not to spend any time on this because longevity of player engagement is not their goal (if anything, the opposite is more profitable for them).