The benefit of having a different file per endpoint is simplicity during initial programming. The downside of such an approach, as compared to a front controller, is complexity while maintaining.
Each of those files will need to parse its input, perform CSRF checks, and generate output. This code is duplicated tens, hundreds, possible thousands of time. Duplicate code is hard to maintain, because any change requires modifying many files. To make matters worse, this is almost impossible to unit test or reuse in different contexts, because the logic inside the files is directly tied to the HTTP input and output. Also, if you ever decide you need to do a deep refactoring, all of your URL's are changing as well, since there is no separation between the structure of the business logic and the layout of the URL space.
In contrast, a front controller can isolate business logic (in the controller methods) from the mechanics of input parsing and output building. It allows for a central place to handle common logic like session handling and CSRF checks. It also allows for decoupling URL from business logic, enabling deep refactoring without user-visible changes. Unit testing the isolated business logic becomes much easier, as well as reuse in other contexts (e.g. in background job queues). There are very few downsides. The code becomes a little harder to understand until you figure out how URL's are mapped to business logic (which will be a standard way for that framework), and the added layer of abstraction can have some minor performance consequences.
The strong benefits of a front controller over the one-file-per-endpoint approach is why all modern frameworks use this approach.