Can you please adapt it so _template can be an absolute path?

Nice one! I cannot test right now though, I might do it over the weekend (do not hold on me though).

I took the liberty of doing some formatting changes to the header of the new file, what do you think?

#.rst:
# ECMConfiguredInstall
# --------------------
#
# Take as ``.cmake.in`` file, runs ``configure_file`` and installs it in the
# given location.
#
# ::
#
#   ecm_install_configured_file(<FILE> <INSTALL_DIRECTORY>)
#
# Example usage:
#
# .. code-block:: cmake
#
#   ecm_install_configured_file(foo.txt.cmake.in ${KDE_INSTALL_FULL_DATADIR})
#
# This will install the file as ``foo.txt`` with any cmake replacements made
# into the data directory.
#
# Since 5.69.0.

#=============================================================================
# Copyright 2020  David Edmundson <davidedmundson@kde.org>

Also, not sure whether you need a .rst file in the docs/module/ directory.

A .rst file in the docs/module/ directory is needed, otherwise the documentation generation will not pick up this, as it runs only over docs/.
Please enable the documentation generation in your ecm build and check for yourself, by e.g. ensuring BUILD_HTML_DOCS is ON and browsing the generated html in the build dir.

That might also show that leaving empty lines without leading # as treated as limit for the documentation IIRC, so all lines which should belong to processed docs need a leading #, other than what the current patch does.

Next I wonder why ".cmake.in" is an expected suffix here. That seems 2x suffixes used for input files. Usually in build systems input files have the suffix ".in", while with cmake there has also been a pattern of ".cmake" introduced, for whatever reason not liking .in. Having both suffixes at the same time is surprising and odd to me, what do I miss?
IMHO the code should rather support both ".in" and ".cmake" (first test the one, otherwise the other), and perhaps for covering Plasma needs additionally ".cmake.in" first, if you have too many files already with that pattern to fix this with the actual files instead rather.

For the actual macro signatur, I wonder if something like

ecm_install_configured_files(TEMPLATES <file> [<file2> [...]] DESTINATION <INSTALL_DIRECTORY> [COPYONLY] [ESCAPE_QUOTES] [@ONLY] [COMPONENT <component>])

would not be better:

• allows to handle multiple files if needed in one go
• argument block names (TEMPLATES, DESTINATION) makes the code easier to read where the macro is used IMHO, and also allows extensibility in the future, if more arguments are found to be useful.
• enabling to pass COPYONLY, ESCAPE_QUOTES, @ONLYon to configure_file() might be wanted as well
• COMPONENT is underused, but some use it, so wanted to be passed on to install()

Would be interesting to see actual examples where you made use of this new macro and how it improves things.

Also missing; unit test (sorry) :)

I agree with almost all those suggestions. Though it's a lot more complex, so I might need some help with some of that.

As for intended usages, it came up on: D28305 for a lot of .service files with a binary location that needs to be derived at configure time.
But it seemed if I made it generic enough it was a pattern that showed up in other locations as shown by porting remaining bits of plasma-workspace: D28422

Quick review while I had some spare minutes, to keep things going.

Are we stuck somewhere? The patch looks good to me.

A bit unsure if the arg name "TEMPLATES" is good, or if perhaps should be renamed to "INPUT". Just mentioning, not preferring one over the other. So far have not found existing samples to take as lead for consistent argument naming.

For completeness, would be good to test for presence of ARGS_DESTINATION, given this is a required arg, and do an error report, instead of falling flat internally on the install() command.
ARGS_TEMPLATES should be fine to be empty, no need to error out on that, might happen if input on caller side is based on a var which gets filled conditionally and might eventually end with empty list,

And while talking checking input, I recently learned about the foillowing handling, and think it provides users of the macros some service in case of typos or accidental misuse, so propose to also add here:

if(ARGS_UNPARSED_ARGUMENTS)
  message(FATAL_ERROR "Unknown arguments given to ecm_install_configured_file(): \"${ARGS_UNPARSED_ARGUMENTS}\"")
endif()

Otherwise looks good to me as well, no showstoppers on my mind. Not yet tested myself though, only looked at patch code.

Moved to invent.