WordPress Hooks : Where to place callbacks that repetitively yield the same effect?

Long-running software may be able to register functionality once and leverage those registrations for every connection across the lifetime of the process, but in the case of WordPress (and most of the PHP web software landscape as a whole) the long-running connection management is offloaded to the web server software. WordPress executes from the top for each individual request – so short of implementing a web server extension or standalone process, WordPress extensions cannot really implement or use a common runtime environment shared between requests.

This generally isn’t anything to sweat however. WordPress’s hook system embodies an event system, and registering even handlers/hooks is a negligible operation – even if you’re registering thousands of hooks there’s unlikely to be any notable performance overhead, as each is little more than inserting a new item into an array.

The same is mostly true for registrations of other types as well – post types, taxonomies, admin pages, REST routes, etc.

You could store some sort of state in the database – but database interactions add a considerable amount of overhead compared to just recreating the state in code. Loading some sort of stored state would be performing the same work – “pushing the same items to the same arrays” – just with additional work to retrieve them first.

Since WordPress only executes the actions/filters which are relevant to fulfilling the current request, if your registrations and functionality are hooked to the appropriate actions & filters, then they won’t execute when they’re not needed. For instance, in the course of serving a front-end page request the rest_api_init action will never fire – so your 30 REST route registrations will never execute, and when fulfilling a REST request the wp_enqueue_scripts action will never fire, etc.

PHP does interpret all of the code in a file when it’s loaded – so even functions which will never execute will be interpreted. But this too is generally negligible – PHP interpretation is fairly fast, and often getting faster. It is possible to split your code into multiple files and only load them if necessary/use an autoloader to that end – but generally interpreter overhead is not a motivation for doing so. Usually it’s just a matter of code organization.