Sounds positive, but the article skirts over whether there are any downsides. Surely there must be lots of ways this could get abused?
(presumably that's why it sits behind Developer mode rather than being default)
Symlink vulnerabilities are pretty well understood. Though, people still make mistakes now and then.
Simple answer about one of the most common/dangerous: A symlink could be made to point to a system file. If a program running with elevated privileges could then be convinced to manipulate the contents of the file pointed to by the symlink, whoever could use that program on the symlink could cause it to modify the system file.
There have been real world vulnerabilities like this (I've shipped a few), but they're not super common and they're often limited in their capability to cause damage...they require an elevated privilege app, that is poorly written, that has untrusted users that can poke at it. It probably requires some kind of shell access, or some sort of local account (email account, maybe), in addition to the poorly written program that has elevated privileges.
There's an easy fix for that: allow unprivileged applications to create symbolic links, but by default, only allow applications to access/follow symbolic links owned by 1) the same user that owns the target file, 2) the user the current process runs as, or 3) an administrator. Since people currently can't usefully use symlinks at all except as an adminstrator, that should not introduce any compatibility issues.
Linux has a similar protection mechanism (/proc/sys/fs/protected_symlinks), though it only applies to sticky world-writable directories like /tmp.
