This is either a bug or a documentation issue, but it's important we figure it out.
In Drupal 7, the "rule" is that you need to have the PHP module turned on in order to be able to execute arbitrary PHP code. This was especially intended as a result of http://drupal.org/node/224333#php_permissions and related issues. The idea is that if you want to lock down your Drupal installation from arbitrary code execution, you can remove the PHP module from the filesystem, or block it from ever being enabled via custom code. That way, even if someone stumbles across a computer with an administrator logged in, there is a limit to the damage they can do.
However, the Update Manager functionality breaks this assumption. In "normal" operation of the Update Manager, this is certainly by design (as the entire purpose is to let you upload arbitrary code to your server) - however, in normal operation it also asks you for your FTP or SSH credentials right before letting you upload, so that's fine because if someone knows those they can already upload things to your server outside of Drupal.
But for certain server setups (in particular, situations where the webserver user owns the Drupal files - i.e. setups that are popular in shared hosting) the Update Manager does not ever ask you for a server password (this results from #609728: Skip authorize.php step if webroot files are owned by the httpd user). It just lets anyone logged-in with the 'administer software updates' permission upload modules to the site.
We need to decide if it's acceptable to allow that with the PHP module turned off. If it is, we need to document somehow that disabling access to the update manager (which can be done through settings.php) is sometimes necessary as part of any procedure to disallow direct arbitrary code execution (without knowledge of SSH/FTP passwords) on a Drupal site. Right now, I don't believe there is any indication of that.