Do you believe that you'd talk about those glue-like subprojects and scripts more if they were written in Java? It sounds to me like your core application is written in Java, with supporting roles going to Perl. If that's the case, then the problem is likely more about representing that aspect of your project effectively to management than overcoming a language bias on their part. To management, a single large project with a proper name and associated mental image that can be sketched on a napkin for the marketing department is a far more tangible thing than a nebulous collection of command line tools you have for operating the system under the covers. It's kind of like asking your mechanic how the repairs are coming along only to hear about his method for organizing his tools. That might matter greatly to him, and to be sure it impacts the repair process, but it's not a good answer to the question "Do I have to take the bus again?"
If you feel those aspects deserve greater attention from management, draw up a comprehensive map of how the various components fit together, showing the gaps that must be filled in. At that point you can talk about how important Perl is to the project.