Recursive replacement is somewhat of a WTF yes but not really in a causitive relationship ro this vulnerability, right? The main cause is the order in which ${} variables are evaluated. They are evaluated after substitution of `{}` in the format string, instead of before. That's the key behavior problem.
A simple rule such as "If you evaluate a placeholder of type `{}` you should stop evaluating further recursively" would maintain most of existing behavior while only removing vulnerable behavior.
From https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/...:
> Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced.
And an example where this caused problems for someone:
https://www.tasktop.com/blog-under-construction/log4j-2-the-...