On the plus side:

1. the ctor establishes an invariant for the object, that it has open filehandles for its other methods to work with
2. as pointed out elsewhere, the dtor (DESTROY) will undo the work of the ctor, releasing the resources
3. the resource usage scope tracks that of the object, which fits the 'Resource Acquisition Is Initialisation' (RAII) admittedly more of a C++ thing but also easy to understand.

On the minus side:

1. You're consuming a resource (3 open filehandles). This is 'small' (~1024, configurable) and finite on some platforms (most Unices, not Windows). This might not matter, depending on how many of these objects you have, their lifetimes etc.
2. You've added state to the object. This doesn't really matter if the filehandles are only closed by the dtor, but if a method can close them then the object now has 'open' and 'closed' states, with some methods only being valid in some states ('open'). This can lead to maintenance issues, since you've added an (implicit) ordering to the object methods.

If there is a single, required ordering to the methods of the object (e.g. instantiate, call 'print_data', call 'close', destroy) then one thing to consider is making that ordering explicit - with a good old fashioned procedure (or class method). To avoid an over-long sub, you can leave the functionality broken out into methods, but make them 'private' (in perl, this is traditionally done with a leading underscore on the name and not documenting them as part of the object's interface). I guess the file handles could then live as lexically-scoped vars of that procedure.

From what you say, its possible that the object has been created to break up a long subroutine, pushing some of the sub locals into object member vars. If so, bear in mind that the original solution had the sequencing of operations and that is lost (except at the calling site) by this refactoring. Since the ordering is part of the object's knowledge, it should live within it (as a class method) and not at the call site.

Lastly, it can be worth thinking of the member vars as 'has-a'. If the object *has* filehandles, then make them member vars (e.g. a logging class). If it just interacts with them (e.g. opens file so object can be serialised) then perhaps that resource is better owned by something else and passed in as a parameter.