I had the same thought. However, I think it's a more generic attack. If you can persist or inject the jdni strings, there's a chance they will be emitted by another component which analyzes the logs and has a log4j dependency elsewhere in the stack.
I've heard people talk about this problem with analyzing windows event logs using Java-based software.
That's interesting. It seems a bit weird that a log analyzer would need to do additional logging, but maybe that's the case in larger systems. I wonder if using log4j as a tool for log analysis as opposed to generation might be a shadow use case of the library. You could have an app that parses log files, converts them to Event objects and then processes that event stream through log4j. I have no idea whether that would be terribly useful and is actually being done by anyone but I guess that's one scenario where these CVE's could cause delayed effects.
I've heard people talk about this problem with analyzing windows event logs using Java-based software.