There are, of course, many pragmatic ways to look at this, and in all cases I would encourage you (first of all) to “be pragmatic.”   “You created an issue-tracking application that, I presume, has been reliably in-service for the last two years ... congratulations!”   Could you have done it differently?   Of course you could.   But, you did it, and that’s always the first hurdle.   Any locker-room analysis that may take place at this point will be from the proper point-of-view:   “how did we win?”

These days, most applications of this nature are built using some sort of “framework,” which captures “a wide swath of possible URLs,” parses them according to some set of rules, and uses this to dispatch the response to one of several subroutines within the umbrella of a single Perl module.   Templates are used to create the actual HTTP responses, and the framework may or may not stipulate what the implementation of the buttons, hyperlinks, and so-on within the displayed HTML “ought” to be.   (And, implementors may or may not follow those rules!)

Basically, I would suggest that you should ... first of all, “go ahead and rest on your laurels.”   I would not in any way disturb the application that you deployed, and I would neither praise nor apologize for it.   In the future, you might well wish to consider the paths that have been blazed by other frameworks (and in many programming languages).

One of the very-clear objectives of these frameworks’ designs is the desire to consolidate functional code.   If you canvass your “10 small scripts,” you will likely find that they have a not-insignificant amount of source-code and functionality between them ... unless you use common modules in all of them.   As you contemplate your next Successful Project, consider how you might now approach it within the auspices of a framework, Perl or otherwise.

But, “style, et al, always is relative.”   I do not believe that there are any absolutes.   Every project is different.