It's bad practice because if you access object data from outside the object's class, you make it difficult to change how that object operates internally later. One of the goals of OOP is to present a well-defined interface to the outside world (a class's methods) so that you can refactor the inside while keeping the client code the same.

Suppose that in a new version of your class, you change how the data is represented internally in the hash. You also change your accessor methods to deal with the new data format and you confirm that they return the same results as before with unit tests. As long as everybody was using the accessors to get the data, everything's hunky-dory. But that one guy who accessed the hash data directly will now have broken code.

Ahhh, I see. You were speaking in general, right? - while I was speaking specifically of Win32::OLE.

With Win32::OLE, the hash syntax is documented and seems to be the preferred method of accessing a property. The properties are defined by the app's (in this case Excel) object model, not Win32::OLE, giving a well-defined interface for automation.