Scripts take up some space in memory, but a larger script covering the same job would generally take up the same amount or more. So you don't save anything that way.
If you have many instances of different scripts and you combine them into a single instance of a master script, you reduce the memory overhead of each individual instance, but this is normally not something that breaks the bank. And you might increase the complexity and potential for bugs by combining many different responsibilities into one script this way.
Scripts with an
LateUpdate, etc.) need those methods called every frame, and that method call cost adds up even if those methods don't do anything. But the example you've shown doesn't have such a method, so that doesn't apply here.
For the script example you've shown, its main runtime cost is in invoking its collision handler.
If you replaced this script with a different script that also does the same job, you'd still have to invoke that collision handler, so that cost would not decrease.
(Technically it's possible to get a savings here if the needed part of the larger script was already in the instruction cache, so you don't need to go fetch a new version of it from a different script. But if you have a project with lots of different behaviours used a few times each, then it's not especially likely that the needed snippet will reliably be in cache the next time you use it - so I don't expect that will benefit your case).
If that new larger script does other things in its collision handler, then you'd need to add some extra logic to check whether it should do those other things, or do just the things that this smaller script does. That extra logic could increase the runtime cost.
So, refactoring this into a bigger script is likely to be a pessimization.
If you want to optimize this script, there are two things you can do:
Invoke the collision handler less often
Do less work each time you invoke the collision handler
You can get both of these at once by using physics layers instead of tags to separate your projectiles. Create a "Projectile" physics layer, and a "Projectile Detector" physics layer. Put all your projectiles on the projectile layer, and this script's object on the detector layer. Set the collision flags so that the detector layer collides only with the projectile layer.
Then you can remove the tag check (which should have been using
CompareTag() anyway, but that's beside the point). Only projectiles will be able to invoke this collision handler, and every other object will be ignored automatically.
So, fewer invocations, and less work checking inside each invocation.
In terms of general practice advice: I would say favour small scripts that do just one job. Small scripts with a simple defined purpose (Single Responsibility Principle) tend to be easy to reason about and maintain, and less prone to developing bugs than massive scripts that try to do a lot.
Profile your game regularly, and use that evidence to find whether there is a particular script that has an outsized impact on your performance, rather than being suspicious of scripts overall.