I know what you mean about stack traces being big, noisy, pointless things -- and I totally agree. But it may be that the uses I've seen and had for carp/croak haven't been so "deep" that their output has been a problem for me.

On the contrary, I've been really grateful for all the times where a given method or function from a module is being used in a lot of different places in an app that I'm working on, and when I make a mistake, carp or croak tells me which line number in calling code triggered it -- without a whole lot of other useless trivia (all the args passed at every layer of the call stack, what their memory addresses were, what the command-line looks like as hex bytes, blah blah blah...)

(My colleagues who use python don't seem care much about error reports -- every time one of their python scripts hits a dead-end, the user gets several lines of doggerel with seemingly random white-space/line-breaks and rarely a legible word, let alone a coherent phrase. Even for cases where the user just needs to be told "file foobar not found". I don't understand why anyone would want or allow errors to be handled in such a way. But I generally don't see this sort of thing with perl code using carp or croak.)

If you feel that users of your module are very unlikely to call a given method or function from more than one spot in their apps, don't worry about it. But if it's likely that one app might use a given sub in lots of different places, you'll probably be doing the module user a very big favor by telling which line in the caller's code caused a given problem.