You should probably expand on that

Sorry - yes. There is a distinction in my head that I failed to articulate.

This module is destined for CPAN. I alluded to this by saying it would be used by other people and I have no idea what they might hang on the callbacks. Code that I write, and post here that uses non-core modules is generally for my own internal use, so whether the modules are core or not doesn't matter. What matters is whether I can install them or not!

Following the release of Business::Stripe::WebCheckout I am really surprised how many people have contacted me about it. So people are using it. I already have working code that deals with Stripe subscriptions and webhooks. I need to use the same functionality on another project so decided to write a couple of general-purpose modules that do the heavy lifting and make those available on CPAN. Hence why, in this case, I would prefer to use core modules.

Thanks for providing the clarification.

I can understand avoiding CPAN modules that require additional (non-Perl) libraries, have complex dependencies, or even those that need a C compiler to handle XS code. Beyond that, I wouldn't not use a CPAN module simply because it's not core.

Ref::Util will use XS code if a C compiler is available; otherwise, it falls back to pure Perl (see the last dot point in the DESCRIPTION). Other than that, it only has a handful of core module dependencies (see its Makefile.PL).

— Ken