The general reason to lock services like this is to prevent an attacker from registering an SES account, rerouting mail through their account, and then turning on some debug options in SES which let them read mail (for example). Generally, I've locked the account IDs for all configurable services.

If an attacker can somehow get a bad svn on the system, this could let them execute it by putting the path where it is located first. This just raises the barrier to executing an attack, it doesn't prevent anything specific on its own.

Mostly, in general no one should be setting this.

Service lock.

This doesn't prevent anything specific, but in theory an attacker could some day use this to get code in the daemons running as a different user than it is supposed to, which could be bad.

All service locks.

This doesn't really prevent anything specific, but other domains have cookie issues and this one may have similar concerns in the future.

(An attacker could maybe set it to point at a proxy they control, then learn the URLs of files.)

Locking the hash secrets prevents an attacker from changing the value to one they know/control.

Prevents an attacker from enabling this if administrators have disabled it.

Service lock.

Prevents an attacker from setting the local disk path to something like the path to phabricator/, which could help them upload files to places they shouldn't be able to. I can't think of any specific harm this could cause (they don't control file names) but this generally raises barriers.

An attacker who managed to get files elsewhere on the server could theoretically load and execute one as a phame skin, maybe.

Service lock.

Like the other filesystem stuff, this is a general filesystem lock and prevents attackers from getting files to write to unexpected places.