This is pretty wild. It's common to have a Drupal site (and probably most PHP-based projects) with permission to write-then-execute, also. On some of the more robust CMS-specific hosting platforms, there are host-imposed limitations that only allow scripts to be executed from certain locations, and those locations are not writable by the user that the scripts run as (e.g., Acquia) -- in fact only the git/CI user can write to the script locations. All user-generated-content that has to be on disk goes off to the side in a directory that expressly will not execute PHP. The downside is that you give up letting the site itself be your update GUI, and for less savvy users (e.g., without knowledge of permissions, git, etc.) I guess that's a big downside. But this is what happens.
Of course, permission to write to disk isn't exactly a hard requirement for a backdoor to arrive (see Drupageddon). But it certainly opens doors, one might say.