New(ish) projects using popular PHP frameworks typically have all their code stored somewhere outside of the web server's document root - there's usually just a

New(ish) projects using popular PHP frameworks typically have all their code stored somewhere outside of the web server's document root - there's usually just a single PHP file in the document root that's responsible for instantiating a front controller or bootstrapping the app in some other way, with a .htaccess (or similar) file telling the web server to redirect all requests to that file. Drupal (and WordPress, etc.) come from a time where your entire code base would live in the document root, so knowing the path to a .php file is often enough to execute the script. While it would be possible to limit this with something like .htaccess, it's error-prone, web server-specific, and can break existing code in your ecosystem, so that's probably why it's not being done consistently. Changing the code structure of Drupal in a way that would put most of the code outside of the document root would similarly cause a lot of work for the ecosystem and might make installation in typical shared web hosting environments impossible in some scenarios - I've seen hosters who only allow you to upload files straight to the document root, so there'd be no way to use such a project with those plans. This is in essence just another case of things going wrong because compatibility was prioritized over possible security concerns, and I don't even want to blame them too much for that, given the usual outcry when backwards-incompatible changes cause work for (plugin) developers in general.