One question, what's the value of the methods in the parent like find_fur_texture, vs. simply calling the method from the child directly?

Think in terms of a client/server architecture: a class (or an object instantiated from that class) is a server, and code which calls its (class or object) methods is a client. A server’s interface should publicly expose only the services it offers. In this case, find_fur_texture is a service (class method) offered by package Monk; the fact that it happens to be implemented inside that class by calling a class method in package Monk::Data is the sort of implementation detail that should remain private to the Monk class.

Put another way: the client code’s access to the services it requires should be kept as simple as possible. Thus, it should use Monk; but it should not have to use Monk::Data.

As Anonymous Monk and kcott have pointed out, there is no need (in the code shown) for package Monk::Data to use parent 'Monk'; — as kcott says, that looks like an OO design flaw. But I agree with kcott in seeing no problem with package Monk useing Monk::Data — that’s simply a part of Monk’s implementation.¹

Also, one of the things that concerned me when reading the warnings about inheritance was the idea of calling the methods by name (ala, Monks::Data::get_texture) as opposed to something more abstract.

I don’t see a problem here. As stated above, clients of the Monk class shouldn’t need to know about the Monk::Data class at all; but clients of Monk::Data have to know the names of its methods, otherwise how can they call them?

In regards to the last bit, one example would be a 2d hash with a bunch of compiled regular expressions that I'm using to parse the data that the module deals with.

This doesn’t sound like a large data structure, only a collection of individual regexen. However, if you do have a data structure large enough to make the costs of copying prohibitive,² that probably indicates that the data structure should itself be encapsulated into its own class. Then Monk::Data can hold and return an instance of that class³ without breaking encapsulation.

¹Yes, this creates a transitive dependency, but that’s really only an issue in compiled languages (see, e.g., the so-called Pimpl idiom in C++). In an interpreted language like Perl, the dependencies to be avoided are those which force client code to be rewritten when the server’s implementation code is changed.
²Beware premature optimisation. Always test your code and profile carefully before expending effort on optimising something that may well be fine as it is.
³In Perl, objects (class instances) are actually blessed references, so passing an object requires little overheard: only a pointer is copied under the hood.

Hope that helps,