I've seen useful modules that were really only one line. But, of course, most useful modules are more than that. Some problems demand quite a large module. When part of the module's functionality can be split out into a logically consistent separate module (or even just a separate package), then that is often wise. If you can come up with a good name for this separate piece, then that is a good sign that you've identified a set of features that makes sense to separate (and coming up with a good name is extremely important when factoring out a chunk of features / code).

So about the only time where size is much of a conern for me as related to modules, is when the implementing of a module calls for several small packages and I wonder if it is better to implement all of the packages in one file or split some or all of them into separate files (and there aren't other more important factors motivating that decision -- usually one package per file is best). Or, rarely, as a "red flag" telling me that I did a poor job of factoring the module's too-large functionality or of "reducing scope" to produce a manageable feature set.

So, for modules, I think it is much more about the size and cohesiveness of the feature set than it is about number of lines of code. It doesn't take all that much to have several hundred lines of code in a module so I wouldn't consider 1000 lines of code in a module to be a "red flag".

For subroutines, single-line subroutines are often useful, of course. But here I put a much stronger upper limit on what I consider appropriate size. Subroutines are a basic unit of abstraction so each one needs to be easy to understand as a unit. So I'm very much against overly long subroutines. I prefer subroutines of a couple dozen lines or fewer, so that they fit in a standard terminal window (24x80). In practice, I don't find this metric too difficult to stick to, especially in Perl, but I certainly don't consider it a hard limit. It is easy to justify going over, especially when coding style guidelines demand near-waste of vertical space with unnested opening curly braces, extensive intra-sub comments and vertical whitespace, or (as mine do) don't allow for flow control stuffed into a single line. But I'm very reluctant to leave a subroutine of over about 60 lines.

If I can't view the entire subroutine at once on a larger-than-I-usually-use window or a page of paper, then it detracts from my ability to quickly and clearly understand it. And, of course, having a good name for each subroutine is very important, though many of those names only need to make sense within the context of their surrounding code.

There are, of course, cases where it doesn't seem convenient to split subroutines down to that small of a size. And you don't want to get bogged down obsessing over how to meet some arbitrary size limit, especially since not seeing how to do it often means that if you do it anyway you'll do it poorly. So putting it off can be a wise choice (and procrastination often means not having to do it). My experience is that such difficulties usually stem from missing a good factoring angle or technique. For example, making the code driven by data and having the data expand beyond one screen-/page-full is one technique. I don't mind repetetive data spanning pages nearly as much.