Your exact question was "Is it really a good choice optimization-wise? What do I loose because of this?". But please hear me out until I get there.
A large quantity of files is, by itself alone, not a problem. Loosing track of what exists in your project due to lack of organization or information gathering techniques and doing duplicated rework because of it is the real problem. And even loosing track of things is not a game related problem, it is only a developer workflow problem. Ideally one should not solve a workflow problem by penalizing or constraining the game (but an indie solo dev life teaches the opposite is often required =P)
Using command line tools one can easily gather quick information about the project. With this:
find . -iname "*.gd" | wc -l
You can see how many scripts you project has. And with this:
find . -iname "*.gd" | sort
you can list them all. If they have good, descriptive and meaningful names, you can also remember a lot just by looking at the list. The same can be made with any kind of file by replacing ".gd" with any other file extension like ".tres", ".tscn", ".gdshader" and so on.
You could also list all functions in a file with this:
grep -ni '^\(static\|func\)' ./Utils.gd | sort
Or all functions in the whole project with this:
grep -rni '^\(static\|func\)' ./ | sort
The same applies for counting functions instead of listing:
grep -ni '^\(static\|func\)' ./Utils.gd | wc -l
grep -rni '^\(static\|func\)' ./ | wc -l
Assuming that your functions have good, descriptive and meaningful names and parameters, just looking at the signatures is enough to remember a lot even if it's been years since you last used them. If you also create a comment documenting the function behavior at the end of the same line as the function signature, those greps alone will get you not only the signature, but also that comment, which is all the info you need assuming your description is complete and concise.
But back to your questions. There's the optimization one and the 'what I'm loosing' one.
About optimization, there are a lot of different scenarios: on some you need to save ram, on other you need to save network, and on other you would save processing and so on. You cannot expect to save everything, you should prioritize.
Assuming you prioritize saving cpu cycles, having 100 instances of 100 different scripts or the same script doesn't make a difference, what matter is what is being processed each frame on process or _physicsprocess, or on 'coroutines' that process every frame or several times a second. So I think your new approach doesn't penalize cpu by itself.
About what you're losing, I think enforcing a give pattern or structure to a project because it seems a better general solution may not always be the best option, even more on game related projects where the kind of problems to solve are always very broad.
The thing is that "general solutions solves general problems", but in reality general problems doesn't exist, what exist are several specific problems that may or may not have varying degrees of similitude. In one specific scenario it could be best to use a script built into the node with very specific behavior, in other scenario you could use a script saved as it's own file that can be used by other objects. In other scenario you would connect signals on the editor and on other you would do it via script. In other scenario you could use heavily OOP principles and class inheritance and in others you would make an Utils singleton with a bunch of small static functions and make things without creating barely any class.
What I'm saying is that I think it is best to cater the solution to the specific problem. Maybe your specific problem was a workflow one, so the specific solution would be related to altering your workflow, not the game. And even if you new code structure and patterns prove very good to you, you should not refrain from escaping from the pattern at times when it proves better to the specific problem you may be facing at that time.
I hope i haven't solved your problem, but rather broadened your view on the problem =)