Would it make sense to have this option with the macro? This way we make sure it's easy to disable and we save some boilerplate on every project.

Yes, asked myself the same when doing all the patches for all the KF modules :)
My answer to this has been:
this might be too aggressive to non-KF projects which might want to use these macros, but with other option name, other default setting or even unconditionally.

It rather points out another problem: there is right now massive cmake code duplication in all the KDE Frameworks modules.
IMHO it would make more sense to invest into some ECMKFSetup & Co. macro set for de-duplicating all the repeated explicit logic across all the modules, also to keep & improve consistency between all the modules.

I know this from other projects where it's successfully done, e.g. in Okteta for each of the currently 6 libs then to setup all the header installation, cmake/pkconfig/pri file generation code is as simple as:

okteta_add_library(Gui NAMESPACE Okteta
    PUBLIC
        OktetaCore
        Qt5::Widgets
    PRIVATE
        KF5::I18n
        KF5::ConfigWidgets
    VERSION     ${OKTETAGUI_VERSION}
    SOVERSION   ${OKTETAGUI_SO_VERSION}
    ABIVERSION  ${OKTETALIBS_ABI_VERSION}
    SOURCES   ${oktetagui_LIB_SRCS}
    HEADERS   ${oktetagui_LIB_HDRS}
    CCHEADERS ${oktetagui_LIB_CCHDRS}
    NO_TARGET_NAMESPACE
    NO_VERSIONED_INCLUDEDIR
    NO_VERSIONED_PACKAGE_NAME
)

okteta_add_cmakeconfig(Gui NAMESPACE Okteta)

okteta_add_qmakeconfig(Gui NAMESPACE Okteta
    DEPS OktetaCore widgets
)

okteta_add_pkgconfig(Gui NAMESPACE Okteta
    DEPS OktetaCore Qt5Widgets
    DESCRIPTION "Okteta Gui"
)

And any improvements not needing new input data/arguments can be done centrally in the macro implementation, those which are just need visiting of all places to add any new arguments.

Never proposed this so far, fearing the rather big work to implement that will get on my desk :P But very much think such KF-specific generic convenience macros would improve things for KDE Frameworks.