return a hashref with output names as keys, and file contents as data values (caller can write them out himself)

The only thing this would do is force most of your users to use the same boilerplate every time they used your module:

for (my($file,$data) = each %returnedhash) {
    open my $f, ">", $file or die "$!";
    print $f $data;
}
[download]

And we all know that boilerplate is generally bad. Modules are written to avoid boilerplate, not create more of it.

If you're afraid that your module might occasionally generate invalid data, and you don't want to clobber their files with it, I can sort of understand your reluctance. But believe me, if you provide them with data and a filename, they will clobber their own files happily, and still blame you for any problems that may occur. The only difference is that they will be cursing you for an inconvenient interface as well. :-)

If, on the other hand, you're confident in your module, then I don't see a problem. As long as the module is clearly documented to clobber files, you should have no reason to be concerned. To that end, your test suite should be heavily loaded towards pounding on the file IO code. This can at least provide a minimum of reassurance.

Update: of course, I agree with all the other fine Monks who recommend having both methods available.