Fun! Welcome to the party 
Putting arbitrary function composition into the string syntax is also contrary to “everything is a command()” design. That doesn’t automatically mean it would make “CMake 4” a worse product.
This is all just syntax, though; the actual semantics are the important part.
If you give programmers a feature, they’re going to use it. And folding it in to string interpolation means that its power increases substantially. Here’s why: before adding it, strings are (concatenations of) strings. After adding it, strings are equivalent to arbitrary CMake code, potentially with side effects. That could range from benign but annoying, like printing unneeded status messages, to quite bad, like unintentionally touching disk in a loop.
I could see programmers doing things like set(_ "${list(${get_args(...)})}") just for the side-effect on a local list. You wouldn’t even be able to see which list it was modifying.
To be fair, other languages have successfully included this feature (eg. Python, Bash, C#, etc.) but I suspect this is because the greater richness of imperative features in those languages makes it less tempting to put real logic there. This particular implementation also treats list return values as parameter packs, which can lead to some unexpected bugs and subtle behavior.
As a counter-point, reading a variable is guaranteed to have no side-effects unlike a function call.
Yeah, it totally is! Giving CMake a unified function return mechanism would let you drop the explicit NAME var. I was working around the fact it doesn’t have one by imposing a convention. The implementation of fun_expr has to capture the function return values somehow.