I’ve always taken the approach of using a plugin on the service if you need the same behavior irrespective of route or consumer. Assuming “modify the plugin” means creating a new bespoke one, then you’re taking on the burden of maintaining it (including debugging it when it’s not working as you expected) which may be more complex and costly in the long run compared with just configuring out-of-the-box plugins on multiple routes.
I’m not that familiar with the inner workings of how Kong (really NGINX) executes plugin code, but I would be surprised if running a given plugin on a couple of routes vs. on the service would be a big resource drain. If you’re running your Kong environment so close to the bone, your bespoke alternate solution might be even more complex to develop/maintain if has to run in a such a minimal footprint.
To get more insight into the performance implications of multiple instances of a plugin, you might also pose your question to the discussions section of the Kong GitHub repo.