Question: Take a random PHP site. It is essentially guaranteed that its web server is configured as follows: serve any file from the document root, except for certain files or paths that are blacklisted. Scripts are also made executable using a similar model: all .php files are executable by the web server except the blacklisted ones.

ASP.NET is configured the same in IIS: \*.aspx files are, by default, executable from any directory, and one is supposed to blacklist directories like a public "uploads" location to prevent vulnerabilities.

I don't know about other web servers, but in IIS it is entirely possible to flip this around, by removing all handler mappings and then whitelisting very specific files / paths. Given a well-structured codebase, one can have just two such mappings: a single mapping for a "/public/" to be served by the StaticFileHandler, and another mapping that maps "/index.php" - and *nothing* else - to the FastCgiModule. For ASP.NET, it's a bit more work, but *if this were a goal*, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.

Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?

Answer: 
Because web-server content changes frequently and it would be annoying to have to constantly add new files to a whitelist.

> 
> For ASP.NET, it's a bit more work, but if this were a goal, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.
> 
> 
> 

But you don't typically deploy .aspx, .php files through a tool. You just drop them in the directory. It would require a huge change in how scripting languages work. They would cease to be scripting languages and become more like compiled languages.

> 
> Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?
> 
> 
> 

Going the other way around would be based on the assumption that allowing user uploads is a normal use-case for everyone installing the webserver. Its not very likely that the majority of webserver instances allow user uploads, as most are undoubtedly corporate intranets or non-interactive sites that simply publish material to the user.
tl;dr: it is expensive 

it works if you have 

* a waf that allows whitelisting + learning-mode
* automated whitelist-generation
* automated deployment-cycles and a full-blown testing/QA - environment that tests ANY new function and feature
* good regression-testing
* ...