You don't mention how these scripts are run, which makes a difference. The preferred style has changed somewhat over the years. When everything was CGI, people tended to use a small script for each function (though that was by no means universal). Early CGIs tended to have all the HTML right there in the script, which was pretty ugly no matter how you did it, so keeping them small helped keep them cleaner. And running each function (add, delete, etc.) through a different URL to a different script often made sense. Also, since (in most cases) each script was compiled and run every time the script was hit, you didn't want to load a bunch of modules and code that wasn't needed for the particular function being requested.

Now that people are using more frameworks and templating systems that keep the layout separate from the code, it's more common to put all code in one file divided up into subroutines. You can still have different URLs, but routed to different subs in one file. The layout code, like HTML, CSS, and Javascript, is in other files. In some frameworks like Catalyst, even code on the other end, like SQL calls, may be in a separate file. So the code stays cleaner. With frameworks and backends like plack, the scripts also tend to be compiled and held in memory, so you don't have to worry about keeping scripts small and light for faster loading. It makes more sense now to get everything loaded at the start so it's ready. It's still possible to break your code up into multiple files for organizational reasons, just not as necessary as it used to be.

Without seeing your code, I'd probably say if it's not broke don't fix it, unless you're wanting to move to a different approach altogether, like going from plain CGIs to a framework like Dancer. In that case, you might ask specifically how people who use the new method tend to organize things.