WordPress's update check on file updates is encouraging insecure website deployments that can be easily hacked. In addition, it promotes a slow way of updating the site rather than a fast way of updating the site.
It is very bad practice to allow the Apache user such as www-data to update the files on the file system. This means a hacker with just the right combination of attack to convice your application running as www-data apache user to compromise your site and re-write your sites files. The proper way to handle this is to restrict your www-data user to read-only access while granting another user (let's call the user dev1) the right to update the files on the website. The way to allow dev1 to write the files but restrict www-data from modifying the files is to have the files still owned a group called www-data and to use the setgid bit on the file permissions of the website so that the files created in the website's group is the www-data group.
You can see what WordPress does described here:
To use the direct method, WordPress should only need to check that wordpress can write the file directly. The current method to check for direct is too invasive and encourages bad user ID permissions or encourages a slow method to update the server.