Not really suggesting a feature. I think this is more of a server administrator's discretion.
But is my suggestion actually true? The whole symlink "issue" isn't so much an issue with server security, it's just a basic misunderstanding of file permissions, something that Linux already addresses. World readable files are world readable. Why get mad at the system for allowing other users to read world readable files?
Granted, some files (most?) don't contain sensitive enough information to worry if they are world readable. A static .html file on your web hosting account might be world-readable... but if I go to your website and read the source... I get the same thing. Changing static files to 640 where the files are part of the nobody group doesn't change anything, because nobody has still got to be able to read the files (where nobody is the web server user). But there shouldn't be anything that sensitive in a static HTML document anyway.
I think a lot of us race around trying to find a solution to a problem instead of working to understand the problem and figuring out if the problem is really the problem.
The symlink hack isn't just a linux file perms issue; it's an Apache issue. World readable isn't the only thing in play here. Just because a file is world readable doesn't make it open to everyone if the directory it falls under is not world readable (or technically, is not world executable). I could have a file set to 777 but if the directory it's in is 700 then only the owner of that dir can actually manipulate or read the file inside it.
The issue comes in because public_html dirs are set to user:nobody, 750. In other words, not world readable. Obviously that's a good thing, however, by using apache to follow a symlink, you gain access to everything "nobody" (Apache) can read. I've worked abuse desks for a long time and this was a huge issue until the rack911/bluehost patches came along. I cannot tell you how many hours I spent restoring peoples backups or even hand cleaning code and databases. You would think that html/php files shouldn't contain sensitive data, but in the case of webapps, they almost always have the DB creds, and that's all you need to hack each site. And you can't just view-source on a php file and get code that's not programmed to display, otherwise every WP site on the internet could be hacked pretty much instantly.
I know in a perfect world people would use Kernel level protections but we can't just force them on people. I know everyone calls the bluehost patch a "last resort" but believe it or not I've seen it do its job extremely well on thousands of servers. Of the many servers I cleaned/fixed before that patch, I've never had to clean one after applying that patch.
I'm glad to see I can finally use ModSecurity with RUID2. This works for me on my own servers, but unfortunately, it's not a config I can force on thousands of users.
I hope none of this sounds rude, just trying to clarify some things as this "hack" is frequently misunderstood.
Also in reference to a previous post of yours, setting php files to 600 (at least ones like wp-config) could certainly help mitigate this. However in this case without RUID2, apache would still need read access to any files it has to serve (images etc) so those would have to be left with higher perms (not a security issue, but more an issue of confused users when php files work as 600 but other stuff doesn't).