No problem!
The advice is just “folk wisdom” that people who don’t really know about the internals of WP’s cron system have copied round in circles between themselves, and has been repeated so many times that people assume it must have something behind it. But actually there’s not much to explain because ultimately there isn’t something behind it; it’s just plain false.
If in your site’s scheduled task list (which you can view by installing a plugin like WP Crontrol and going to Tools -> Cron Events), there is a scheduled task that is due, then WP will seek a way to execute it. That task will require precisely the same amount of resources to execute independently of how you are causing WP Cron to be invoked. It’s like telling someone on WhatsApp to do a task, or telling them by email instead: however they get the message, the task itself takes the same amount of resources.
The implication of the advice is that WP’s default way of looking up the list of cron tasks is inefficient. That’s not true. It’s a list in the database which gets auto-loaded, always, on every WP script load of every type, regardless of how it’s used, and the resources used are infinitesimally small in the context of all that WP does in loading each time a script is run.
The only thing that you can do by running WP cron via a different route is run it too few times relative to the length of the internal jobs list (i.e. to the number of tasks that are due). That “saves resources” in the sense that tasks that were meant to be done at some defined time only get run later (which will cause an item to appear in ‘Site Health’ if you look there). But that isn’t something you want to happen. If a site has tasks that aren’t actually needed, then sticking a spanner in WP cron isn’t the way to deal with it, because that affects all tasks, not just the ones you didn’t want.
It’s for this reason that people who assert that you can improve performance by running WP Cron a different way never accompany this assertion with any measurements – that would be impossible, because there’s really nothing ultimately behind the assertion.
