Code is not going to become more secure per se by splitting it differently across files. The important thing is what code is going to be executed when anyone requests a certain URL. Whether this changes because your web server is executing a different file or because you have an
if..else statement in one file is entirely irrelevant. Separate files may help code organisation and thereby prevent possible bugs, but it's not more secure per se.
If it's possible to access "include files" which should not generally be executed by themselves, and this allows an attacker to circumvent some protection or another, that's entirely your fault for exposing this executable code publicly in the first place. You must only place "public" code in the public webroot directory. If a visitor is not supposed to go to
http://example.com/include/never/execute/this/directly.php, then this URL must prompt a 404 response by the web server instead of making it execute some code. The sane way to do this is to not put the file there in the first place, but outside the webroot:
This can go so far as to only have one
index.php in the webroot, using mod_rewrite to direct all requests into it and using a request router to handle requests in PHP.
Your web server is responding to URL requests. This has nothing to do with physical files at all. Always keep that in mind. Which URL request involves which files is completely up to you. The point is which URL will trigger what response; how the files are laid out on the backend is completely irrelevant.