A pragmatic driver of support for serving static files on the web is efficiency
Here is a question that you could ask in a certain sort of mood: why is serving static files from a web server so well supported? It's not universal (there are some web server environments with no support for it), partly because it's not as simple as it looks and you also need something approximating a filesystem, but it's very common and has been for a long time.
Since plenty of people wind up wanting to serve some static files even in an otherwise dynamic application, support for this is widely available and robust in general purpose web servers. Once this support exists for the special case of high efficiency serving of high demand static data (in files), it can usually be reused by people who want to serve static files in general and who don't care anywhere near as much about the efficiency. Everyone gets to benefit.
(A web server usually has to do a little bit of extra work to be a good general purpose static file server, but not too much. This little bit of extra work is one reason why some servers have limited static serving support; for example, they might not handle directories, since you don't need that to serve images, CSS, and so on. As a side note, Apache is unusually capable at serving static directory trees, partly for historical reasons.)
There are a variety of technical reasons why serving static blobs (often in files) has generally been more efficient than dynamically producing the same data on the fly (to the extent that you can do that; some data, like images, is essentially fixed and incompressible, with no meaningful dynamic generation of it possible). Part of it is that many operating systems are highly tuned for efficiently reading data from the filesystem and runtime environments have mostly not been finely tuned to make data generation code as efficient, low overhead, and scalable (especially if you're serving the same thing over and over again).