SOLVED
Right, and so - why this breaks-in-most-environments 'fix' as opposed to say, checking if the uploaded file is actually a valid image file rather than (presumably) previously only relying on mime types (provided by the browser upon upload based on file extension)?
A properly configured environment will not pass jpg/gif/png files through the PHP interpreter for execution, which leaves actual execution of the malicious payload completely dependent on some other mechanism/misconfiguration.
You talk specifically about world-read scripts being executed from other accounts. PHP scripts executed from a different web root or application to the Magento install will only result in PHP executing as the same user as the Magento install if it is installed on an insecure shared environment where PHP executes as the webserver (eg: www-data) which no shared hosting provider (and in fact, nobody running more than one web application on a server) with half a brain has done since like 2001.
World read scripts being executed from another account but somehow as the same system user as the magento installation under attack is not an attack vector Magento should be addressing by making image files 640 - because if someone is able to execute arbitrary files inside the Magento webroot as the same system user that PHP runs as under the Magento install then they can already insert files into folders to which that system user has write access. They don't need to upload some PHP renamed to a jpg inside the admin panel of the Magento installation.
If this is really the vector that is being considered when this change was drawn up: You can't band-aid terrible security practices/configuration on webservers with something like this.
Changing the established security model of a webserver when it comes to filesystem permissions (eg: static content with world-read will be served, static content without world-read is denied) to support this change is a terrible idea precisely because it is non-standard (and likely not possible in any kind of shared environment) - users in a dedicated environment using poor security practices will still be exposed (as they will still be running PHP as a single user).
For everyone else, they're now in a situation where they are being told to modify core files to undo a poorly conceived fix to a problem (poorly secured environment) that wasn't Magento's to address. Advocating for people to make alterations to a core file to undo this is a bad idea for a multitude of reasons, not least of which the fact that a good 20% of people will probably just end up breaking something.
In summary: 
