As with the majority of security issues it was done for convenience. Not every user has access to the hosting provider so it was done out of convenience.
Thankfully they removed this option in Drupal 8, the latest version. You could also restrict users from accessing the functionality so it wasn't that terrible. In practice few sites actually use the option, but when they do it can make troubleshooting a giant pain in the ass.
The fact that php.module ever existed in the codebase is a downright travesty. As soon as any privileged user was compromised (i.e. someone with "administer users" or "administer site configuration" permissions) the attacker had arbitrary remote code execution.
My projects had a patch to remove that entire module from core on each build.
One example I did many years ago: I want to make this download page vary what it serves by user agent, providing instructions for any things they’ll need to install first (because .NET stuff used to go in the user agent string), and providing the appropriate download link for their platform. Most of this could be done in JavaScript, but there was at least one part of the mix that couldn’t be, but could still be detected from the server.
Now which is easier—make a new module to serve this page or filter the output of that page, or just enable PHP code for this page, and write it directly in PHP on this page only?
Thankfully they removed this option in Drupal 8, the latest version. You could also restrict users from accessing the functionality so it wasn't that terrible. In practice few sites actually use the option, but when they do it can make troubleshooting a giant pain in the ass.