The last part advises to be feature conservative to avoid promises all together. For that look to enterprise software where backwards compatibility is a legal agreement. This carries a bunch of alternative issues.
The elephant in the room here is the excessive dynamism allowed by default on the JVM platform. How many applications actually need fancy classloaders? Why isn't every step to get there - "loading a class from anywhere that isn't my JARs", JNDI, JNDI's LDAP backend, etc. - an explicit opt-in flag to the VM? Java's wide-open defaults are what made the blast radius of this huge.
In some ways that is where this and all those features fell down ... if log4j had constrained those classes within a security sandbox it wouldn't matter what they did. But nobody understands or uses Java security permissions. The whole system is byzantine and drives people crazy whenever they do run into it. But if it had worked you could be asking the question, "why did log4j allow the permission for the remote code to do bad things" rather than "why was remote code allowed to execute".