I suppose the only comment I could make would be that you are pushing a lot of this HTML-specific logic rather far away from “the presentation layer” of the program.   If I needed to change the CSS and/or JS library requirements, it would be difficult to do so.

I would first weigh the thought that maybe it doesn’t really matter if the CSS and/or JS lists change from screen to screen given that the stuff will probably be compiled-once and then cached anyway.

As my next thought-strategy, I would consider whether there are not, in fact, “just a few general cases.” If so, I could prepare templates containing the various possible combinations of CSS/Script tags in actual use, and then [%include%] those templates into other templates as needed.

I can, after all, have as many templates as I wish, and I can include common segments (be they CSS/Script declarations or something “visible”) as I please.   All of these strategies would serve to yank those lists of CSS/Script dependencies out of the Perl code, where I do not advise they should be, and puts them into the template system where I suggest that they properly belong.   The page-generating code, using a defined constant rather than a literal string, would specify which wrapper-template should be used.   The common page-generating subroutine would contain the actual logic, once, for invoking the templating system properly, and it would be a common choke-point for detecting errors anywhere in the calling code.

Am I going to “look you up and beat you over the head with a wet noodle” if you don’t do it this way?   No, but I do think that this include-based strategy might play out much cleaner and prove to be much easier to maintain.