Some cross-cutting concerns are about more than just code, but things like "how will you monitor this for reliability?" or "this system reads user-sensitive data, how will those reads be audited?" and so on. Usually the answer is short: "use standard system xyz" - but having it there and ensuring it's followed through on are important.
Fair enough. Definitions can be broad. The term "Cross-cutting concerns" made me think of aspect-oriented software development which has a very specific definition and it tends to favor specific approaches like dependency injection.
For example, in aspect-oriented development, they tend to promote injecting a logger into all the components; but other development methodologies might instead make it so that messages and errors bubble up the component tree (e.g. for non-error messages, might use event emitters, message passing, callbacks, or other kinds of channels). But the idea is that the messages for all components are aggregated, handled and logged near the top level in a central place; so you don't need to inject a logger instance into every component; it loosens the coupling of your components with the rest of your application... Also, logging might be just one of things you do with those messages.
It's nice to have that logic near the top level of the code. I find it extremely valuable when the important outputs of the system (what the developer or user can physically observe) can be traced starting from a single source file (or at least, as few files as possible).
Some cross-cutting concerns are about more than just code, but things like "how will you monitor this for reliability?" or "this system reads user-sensitive data, how will those reads be audited?" and so on. Usually the answer is short: "use standard system xyz" - but having it there and ensuring it's followed through on are important.