Given the simplicity of the program (two nested loops), profiling won't tell you much ("the nested content is slow") until you've done some high-level analysis.

If the nested loops can be eliminated or sped up, improvements will ensue. For example, if it's possible for $domain to have the same value for two rows of DOMFILE, a file is being read more often than it needs to be.

And then there's the three-deep loop at the bottom. Efforts should be placed into flattening those.

Once that's done, profiling could be used to do some micro-optimisations.

Update: That one part of the program is IO-bound and the other is CPU-bound is noteworthy. Maybe parallelisation is an option.

I'm of the opinion that the added understanding gained by profiling is worth it even in simple cases. At the point where you are trying to speed it up, even educated guessing is often wrong. And Devel::NYTProf (which I linked to above) does both line-level and block-level profiling, so it would directly say that the problem is that you are running these loops too often. (Leading the optimizer to start looking for ways to run them less, hopefully.)

When looking at profile output, there is a temptation to focus on individual lines I'll admit; but it can and does help just as much on a broader scale, as long as the programmer resists that temptation.