Yes, it’s good that they changed the default now. But it’s still a design mistake that they can’t distinguish between the log pattern, log message format and logging parameters. If you turn it on, it’s turned on on everything, because the substitution is performed as the last step.
Not really, because log4j now restricts JNDI-LDAP queries to localhost by default, or to an explicitly configured list of hosts. An attacker would have to have access to the application configuration or start script.
No, you are still vulnerable, even with just what we know today and we're still finding more ways to break this library.
1. Attackers can still load code in your class path.
2. Attackers can steal environment variables, VM information, system information, etc.
3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE.
We may find even more ways to attack this in the future. It is absolutely not a good idea to assume you're safe right now - if you have log4j in your dependency tree, you should keep a close eye on the discourse as it evolves.
edit: I'll just say that I think it's really premature to tell anyone that they're safe.
As far as log4j is concerned, the substitutions ("lookups" — this includes your #2) are now disabled by default, and can only be enabled by an attacker if he already has access to the application. I’m not sure what you’re referring to in #1 and #3, given that fix.
By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198
For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior:
log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)