I don't think you understand the risk. Whatever app has the log4j library installed can be instructed to execute ANYTHING.
Say your front-ends aren't vulnerable. But they write out the log messages, your Datadog agent reads them, and viola you're running bitcoin miner software (if you are very lucky it's only that)
Say you don't use Datadog, but your archive your logs. Then you run a batch processor in the background to summarize your logs. And it's vulnerable.. voila, same problem. This little threat can find its way deep into your enterprise stack. It's a hand grenade, just waiting for any unclean hands to touch it.
...and...
You mean log4j 1.x which is 7 years end of life, and has a dozen or more known ways to get RCE which are built into every newbie wanna-be crack kit? That's worse than having the current vulnerability.
Please for god's sake I hope neither of you are decision makers at these firms. If you feel safe because you're using a 7-year EOL library with dozens of known RCE vulnerabilities 
Log4j 2.17.0 has been out for 30 hours... unless Hubitat took an extra step of removing JndiLookup.class from the library, they are vulnerable to one-packet d-o-s total shutdown of the node.
